I wrote about this because it hits two of my current obsessions at once - developer environment sandboxes (for safely running Claude Code etc in YOLO mode) and APIs for executing untrusted code.
That seems fine if you have a box that's running all the time and something like tailscale set up. I haven't bothered because I'm lazy, but I do want any coding agents I have off my laptop and off the local network, because I'm a little wary about them getting subverted. They need Internet access anyway, so might as well.
Since I anticipate using coding agents a lot, that means my dev environment is going to live in a VM in the cloud from now on.
a local sandbox may not be perfectly isolated, unless you’re running it in a VM. But then that takes up local resources. or you’re on the go a lot. a person might not have a reliable local machine or network or be in a position to keep it on and consistent all the time.
>> In a smart piece of design, Sprites uses pre-installed skills to teach Claude how Sprites itself works. This means you can ask Claude on the machine how to do things like open up ports and it will talk you through the process.
^^ So is Claude Code baked into a default sprite? If so, how/who/what API key is paying for CC? (I'm assuming this gets configured some way? Perhaps in just the normal CC CLI way?)
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.
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...
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.
Here's the announcement on the Fly blog: https://news.ycombinator.com/item?id=46557825
I wrote about this because it hits two of my current obsessions at once - developer environment sandboxes (for safely running Claude Code etc in YOLO mode) and APIs for executing untrusted code.
Stupid question but why not use a local sandbox for yolo mode instead of a remote machine.
Is there a similar service that runs locally?
That seems fine if you have a box that's running all the time and something like tailscale set up. I haven't bothered because I'm lazy, but I do want any coding agents I have off my laptop and off the local network, because I'm a little wary about them getting subverted. They need Internet access anyway, so might as well.
Since I anticipate using coding agents a lot, that means my dev environment is going to live in a VM in the cloud from now on.
2 replies →
a local sandbox may not be perfectly isolated, unless you’re running it in a VM. But then that takes up local resources. or you’re on the go a lot. a person might not have a reliable local machine or network or be in a position to keep it on and consistent all the time.
1 reply →
>> In a smart piece of design, Sprites uses pre-installed skills to teach Claude how Sprites itself works. This means you can ask Claude on the machine how to do things like open up ports and it will talk you through the process.
^^ So is Claude Code baked into a default sprite? If so, how/who/what API key is paying for CC? (I'm assuming this gets configured some way? Perhaps in just the normal CC CLI way?)
Yes it's baked in. You as the user pay for a separate Anthropic account and login with that when you first use a sprite.
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
2 replies →
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.