Live data from Hacker News

Git worktrees are not an isolation boundary for coding agents

fletch.sh

31–40 of 43 posts

Re: Git worktrees are not an isolation boundary for coding agents

#31
post #19

Git worktrees are a great isolation boundary for _changes_ (especially making changes in parallel on a single machine), but not behavior. If you are trying to actually run autonomous agents securely you need something that lives outside the harness that actually blocks actions in a way that can't be prompted around. We use nono [1] for this internally, essentially blocking any actions we don't want agents to be able…

"read/write only the worktree", but git requires .git dir writable for common commands to work in a worktree. And that's where .git/hooks live. So agent inside that profile can still write a pre-commit hook that runs on your machine whenever you commit outside the sandbox. Or am I missing something?

All git config and hooks are not writable inside the sandbox. This can be somewhat frustrating as you have to run git config commands outside, but the tradeoff is worth it imo. Nono allows for directory level permissioning, so the entire `.git/hooks` directory and `.git/config` / `.git/worktrees/*/config.worktree` are write blocked.

Worth calling out that this doesn't close all of these types of attacks, just the ones that are invisible (claude could very well write ./hack.sh and tie that in to your main.go, but at least it would be a diffable change, instead of invisible like a git hook)

Re: Git worktrees are not an isolation boundary for coding agents

#34
...concluded anyone who has ever thought about this for longer than 5 seconds.

We have had the tech for isolated, snapshottable, copy-on-write and commit-after-review filesystem workflows around for decades now. How long will it take for AI bros to discover it?

Re: Git worktrees are not an isolation boundary for coding agents

#35
post #19

Git worktrees are a great isolation boundary for _changes_ (especially making changes in parallel on a single machine), but not behavior. If you are trying to actually run autonomous agents securely you need something that lives outside the harness that actually blocks actions in a way that can't be prompted around. We use nono [1] for this internally, essentially blocking any actions we don't want agents to be able…

nono is great but you'll still won't be able to run multiple dev servers, dbs or test in the browser...

the better alternative is using sandboxes, for TRUE isolation.

but most people skip them because it's harder to set up a dev environment in a sandbox, for this I built agentbox [1], a tool to teleport your files, skills, settings, claude/codex subscriptions etc in any of the popular sandboxes. eg:

agentbox e2b claude

or:

agentbox hetzner codex

each session is persistent, with a full VM, with a browser, webVNC screen sharing and local https tunnel for easy preview on *.localhost domains.

Also git credentials never leave your pc: when a box needs access it passes through the agentbox service running on your machine, which allows PR creations, comments but only on the box branch, no deletion etc.

[1] https://github.com/madarco/agentbox

Re: Git worktrees are not an isolation boundary for coding agents

#36
post #30
post #13

Do people not know how to write blogs without AI anymore? I enjoy hearing a human's unique voice and miss hearing it when it's abscent.

I'm setting up my new blog right now. I'm thinkin of having a toggle to "hide" ai generated content from my main list of writing, and labeling (and a disclaimer at the toop of each ai-generated post a message). Example home page: https://taude.xyz/ Example AI Slop post: https://taude.xyz/posts/the-tool-stack-behind-this-blog/ Not trying to self-promote, but honsetly trying to leverage AI when appropriate, and to also…

Very cool. I also like making websites with Hugo, and I have thought a lot about different theme vendoring methods, and how to retain ease of updating and testing your theme.

https://simonshine.dk/articles/vendoring-hugo-themes-with-ni...

Re: Git worktrees are not an isolation boundary for coding agents

#37
post #35
post #19

Git worktrees are a great isolation boundary for _changes_ (especially making changes in parallel on a single machine), but not behavior. If you are trying to actually run autonomous agents securely you need something that lives outside the harness that actually blocks actions in a way that can't be prompted around. We use nono [1] for this internally, essentially blocking any actions we don't want agents to be able…

nono is great but you'll still won't be able to run multiple dev servers, dbs or test in the browser... the better alternative is using sandboxes, for TRUE isolation. but most people skip them because it's harder to set up a dev environment in a sandbox, for this I built agentbox [1], a tool to teleport your files, skills, settings, claude/codex subscriptions etc in any of the popular sandboxes. eg: agentbox e2b clau…

> nono is great but you'll still won't be able to run multiple dev servers, dbs or test in the browser...

With our profile setup you can do all three of those things - there is a fresh chrome profile that is blocked against the same network firewall. Claude and Playwright can navigate to the dev stack and screenshot/test it (and non-allowlisted websites are blocked at the network level).

As long as the developer runs the `task start` command outside the sandbox (because docker is blocked), the agent can then interact with it all that they want, and our devs can run 2-3 of these per machine and work on concurrent projects. (based on memory usage / cpu usage)

> a tool to teleport your files, skills, settings, claude/codex subscriptions etc in any of the popular sandboxes

FWIW this is _explicitly_ the opposite of our threat model - everything other than your git credentials that you 'teleport' in (code, settings, Claude/Codex subscription tokens) now lives inside the blast radius, on third-party infra, and a prompt-injected agent in the box can send it anywhere unless you're also egress-filtering. A VM isolates the machine - it doesn't protect the data.

Much easier to keep it all local and refuse any network or file access to anything you don't explicitly approve

Re: Git worktrees are not an isolation boundary for coding agents

#38
post #36
post #30

Earlier quoted context omitted.

I'm setting up my new blog right now. I'm thinkin of having a toggle to "hide" ai generated content from my main list of writing, and labeling (and a disclaimer at the toop of each ai-generated post a message). Example home page: https://taude.xyz/ Example AI Slop post: https://taude.xyz/posts/the-tool-stack-behind-this-blog/ Not trying to self-promote, but honsetly trying to leverage AI when appropriate, and to also…

Very cool. I also like making websites with Hugo, and I have thought a lot about different theme vendoring methods, and how to retain ease of updating and testing your theme. https://simonshine.dk/articles/vendoring-hugo-themes-with-ni...

Funny, Nix is next on my list.

Re: Git worktrees are not an isolation boundary for coding agents

#40

I haven’t hit these issues when using worktrees. But what’s a pain is having to compile from scratch every time, and not carrying over gitignored files.

Same here, over hundreds of worktrees in months of work. The only problem I ran into was when Codex or Claude Code were configured to create the worktrees nested into the parent repository. Then grep would yield results from a worktree and the agent would happily start to work in the wrong worktree.

[flagged]
Post reply on HN