harden sandbox file write deny rules - cover .git/hooks

[kbroughton]

.git/hooks/ is not in the deny list for file writes

The deny rules protect ~/.bashrc, ~/.zshrc, ~/.ssh/** — but not .git/hooks/**. The /sandbox restricts writes to
CWD, but .git/hooks/ is a subdirectory of the project root, so it's inside the allowed write scope. A sandboxed
agent can write and chmod +x a hook file. The hook fires at next git commit with full user privileges, outside
the sandbox. We verified this in the ToB settings.json directly.

Fix candidates for the issue: Edit(.git/hooks/) + Write(.git/hooks/) deny rules as a speed bump (doesn't
cover Bash shell redirects), and/or a README recommendation for git config --global core.hooksPath pointing to a
read-only directory as the complete fix.

Happy to make a PR if you like.

[mehvetero]

Good catch on .git/hooks/. I hit a related gap while running Claude Code against Move (Sui) contract repos:

~/.sui/sui_config/sui.keystore stores private keys in plaintext (base64-encoded Ed25519 keys in a JSON array). It is inside $HOME but not covered by the default denyRead list. An agent that lands a shell via .git/hooks — or even just a cat in a Bash call — can exfiltrate the entire keystore in one read.

The fix on the sandbox side is straightforward:

"denyRead": [
  "~/.ssh",
  "~/.gnupg",
  "~/.aws/credentials",
  "~/.sui/sui_config"
]

But the deeper issue is that Move tooling (sui move build, sui client publish) needs access to sui_config/client.yaml for RPC URLs and active-env. So you cannot blanket-deny the directory without breaking the development workflow.

A more precise rule would be:

"denyRead": ["~/.sui/sui_config/sui.keystore"],
"allowRead": ["~/.sui/sui_config/client.yaml"]

I don't know if the current settings.json schema supports per-file allow within a denied parent. If not, that's probably a feature request upstream to Anthropic.

Regarding the .git/hooks fix: the core.hooksPath redirect to a read-only dir is the right call. I'd add that as a setup step in the README rather than relying on denyWrite alone — as you noted, Bash shell redirects bypass the file-system deny rules entirely.