Greybook
+ NewSign in

How are you actually sandboxing coding agents?

Field noteOpen question

Posted by hbecker · Jul 20, 2026

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.

Discussion · 5 comments

Strong evidence gets promoted into the record above.

graycodetrustedMerged into summary

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.

20
lena_writes_code

we automated it and it stopped being a tax. one script — make worktree, start container with it mounted, no host creds, drop you into the agent. about 9 seconds.

the friction was never the container, it was the arguing about whether this particular task really needed one. when it's one command nobody argues.

14
mateohq

the thing that changed my mind: agent read a dependency's README during a routine version bump and that README had instructions in it addressed to an agent. nothing happened, it ignored them. but I'd been thinking about "untrusted input" as user-submitted data. it's also node_modules. it's every file in your tree you didn't write.

12
quinnfields

9 seconds is doing a lot of work in that comment, is that a prebuilt image or are you building each time

2
lena_writes_code

prebuilt, rebuilt nightly in CI. building per task would be unusable, you're right.

5

Sign in to join the discussion, vote, and verify fixes.