Comment by vivzkestrel
2 days ago
as a guy who is not in loop with all these sandbox developments, I apologize for this extremely stupid question. Why do we need any of these sandboxes? Why cant we use docker? I thought it was a solved problem 10 yrs ago?
See: A field guide to sandboxes for AI¹ on the threat models.
> I want to be direct: containers are not a sufficient security boundary for hostile code. They can be hardened, and that matters. But they still share the host kernel. The failure modes I see most often are misconfiguration and kernel/runtime bugs — plus a third one that shows up in AI systems: policy leakage.
¹ https://www.luiscardoso.dev/blog/sandboxes-for-ai
I think one difference is that it also provides the service of being a production environment you can serve from at the same time as development. There's more information about this thought in the fly io blog post.
I just use Docker devcontainers using Anthropic's own Dockerfile as a base, and it gives me a persistent sandbox that have ports opened and work in any container environment (be it remote or local), and work in any IDE that supports devcontainers...
https://anil.recoil.org/notes/ocaml-claude-dev
So what if Claude Code makes a mistake and tears up the sandbox? What happens to all the persisted state (aside from the container image)?
The linked fly.io article discusses why containers aren't a good fit for sandboxes that need persistent state and how sprites.dev addresses the challenges.
1 reply →
Maybe it's concerns about docker chroot escape? I'm not sure what the current consensus is on how "secure" docker is, but in the past I've heard you shouldn't assume an app in a container is fully isolated from the "host" system.