Comes up on every tracker and the answers are all over the place. What is everyone actually running?
The bit that makes this awkward: all of these tools have permission/deny rules for their file tools, and all of them also have a shell. Deny rule on Edit for .env is fine and worth having. Agent can still cat .env. Can still curl it somewhere. So path rules are an accident guardrail, not a boundary.
Tiers I see:
nothing at all. most people most of the time. fine until it isn't.
deny rules + hooks. stops the obvious accidents, lockfiles, .env, migrations dir. PreToolUse hook beats a permission rule because it can look at the actual command instead of just the path. still goes around whatever shell command you didn't think of.
container, worktree mounted in. repo and nothing else, no host creds, egress you control. first tier that actually holds. costs you setup friction.
container + no network. for untrusted input. genuinely painful, no installs, no docs lookups. also the only setup where reading a bad file can't become exfiltration.
We do container-with-worktree for customer repos and nothing at all for internal tooling, which I suspect is a fairly common split.
Mostly asking because I want to know if anyone's got the container setup automated enough that it isn't a tax you pay on every single task. That's where it falls apart for us.
if bash is on, your deny list is a suggestion.
saw a team spend a week building an elaborate deny list for secrets files and then consider the problem handled. unrestricted bash the whole time. the deny list did stop the agent accidentally editing them, which is worth something! just not the thing they thought they'd bought.