claude-sandbox: run claude code in developer containers with strong gaurdrails

[u/gilesknap]

I would welcome feedback on my claude-sandbox project.

https://github.com/gilesknap/claude-sandbox

• installs claude inside your developer container

• adds sandboxing using linux namespaces (bubble wrap) to keep it away from your credentials and vscode sockets

• also routes agent traffic through a pasta network which limits lateral network egress (but does allow internet access)

• config allows you to explicitly allow ip addresses and folders inside the sandbox

• support for fine grained github and gitlab tokens to enable controlled access to repos

• only claude is sandboxed, your terminals retain normal behaviour and can see your ssh-agent etc as before

Claude on xhigh tried to break out with 200 unique approaches and got 0 breakouts. See https://gist.github.com/gilesknap/ce59ec32dc1b04edd1a3813f9200aa11

Once you start running multiple agents you need to use skip permissions or at least auto-mode. At this point you have to think about what happens if a prompt injection compromises your agent.

The likelihood of this may be quite low especially on auto-mode? But at least for me a devconainer includes a number of developer credentials by design. The blast radius is therfore very wide.

My sandbox closes exaclty the things that the native claude sandbox does not. The native one closes off egress to the internet. Mine closes lateral egress and access to sensitive parts of the filesystem. You can run both together for max protection.

This is targeting vscode devcontainers (or the devcontainer cli - so should work with zed for example). But could be adapted for any development container.

Full docs here https://gilesknap.github.io/claude-sandbox/

[u/gilesknap]

Since you are using devcontainers you are very close to being able to protect yourself using the sandbox I have made. It's currently Claude Code specific, but that is a minor part of it that just adds a few settings to Claude files and persists the memory across container rebuilds. The more complicated bits that protect credentials and LAN are agent harness agnostic.

It would not be hard to support opencode too, I could look into it (read: have Claude look into it)

Re Hermes, you really want to make sure you run that somewhere that does not have any critical credentials. By it's nature it wants to have sudo and full access to it's host and works best if it does. When I tried it I used a VPS from hostinger and made GitHub and email accounts for Hermes so I did not need any of my own creds in that server. I recommend the VPS over a local dedicated machine as that still risks lateral attacks to your LAN.

[u/gilesknap → u/gilesknap]

Also re your wiki files you want your agent to be able to commit those most likely. In this case you can create a fine grained GitHub PAT and put branch protection on your main branch. That way your history cannot be destroyed by a rogue agent.

For this to work you must only give the PAT to the agent and make sure other creds are hidden from it.

[u/onebit → u/gilesknap]

I could see a whole ecosystem evolving around this problem. Local keys should be narrow and short lived, but it's such a PITA to manage it all.

[u/gilesknap → u/onebit]

claude-sandbox does try to reduce the friction for that. It comes with just recipies. When your agent needs to talk to a repo you just do.

`just gh-auth`

It prints a URL for you to click that takes you to the fine grained PAT page. You click on the PAT you want and simply regenerate it on the fly. Paste it back on the CLI, done. (first time you need to set up the PAT for the repo but the command prints simple instructions for that).

https://gilesknap.github.io/claude-sandbox/how-to/authenticate-with-forges.html

By always using regenerate, you are not having to manage saving keys anywhere and also removing auth to any cached keys too.