Is there an easy way to do something similar for Claude Code? I'm growing tired of babysitting it to make sure it doesn't do anything bad.
Late adopter. Started last night. Stayed up four hours past my normal bedtime because I couldn't stop.
Needed the Max 5x plan after two hours. (The 'Pro' plan should be renamed 'Sampler', made one-time and free with CC details.) Max 5x seems like it can sustain my current appetite.
I very quickly went from thinking it was overpriced (around 100 USD/month) to worrying that this pricing can't last. I think I get about 50 working hours per week with this plan.
Install your OS of choice in a virtual machine, e.g. even hosted on your main machine.
Install the AI coding tool in the virtual machine.
Set up a shared folder between host+guest OS.
Only let the VM access files that are "safe" for it to access. Its own repo, in its own folder.
If you want to give the AI tool and VM internet access and tool access, just limit what it can reach to things it is allowed to go haywire on. All the internet and all OS tools are ok. But don't let this AI do "real things" on "real platforms" -- limit the scope of what it "works on" to development assets.
When deploying to staging or prod, copy/sync files out of the shared folder that the AI develops on, and run them. But check them first for subterfuge.
So, don't give the AI access to "prod" configs/files/services/secrets, or general personal/work data, etc. Manage those in other "folders" entirely, not accessible by the development VM at all.
From within VSCode, you can run devcontainers, which bind mounts the project's directory into an isolated Docker container. Safe for --dangerously-skip-permissions
Tried this the other day and the setup on this is super cumbersome and requires you to constantly rebuild your entire dev and Claude Code environment every time you use a new container, including whitelisting URLs for package managers and the like.
There are techniques to mitigate this. You can reuse containers instead of creating a new one each time. You can mount in directories (like ~/.claude) from your local machine so you dont have to set claude up each time.
Docker desktop has a pretty nice sandbox feature that will also store your CC (and other) credentials, so you don't have to re-auth every time you create a new container.
Funnily enough, we shipped the Docker Desktop VM a decade ago now (experience report at https://dl.acm.org/doi/10.1145/3747525). The embedded VM in DD is much more stripped down than the one in Claude Cowork (its based on https://github.com/linuxkit/linuxkit), and its more specialised to container workloads rather than just using bubblewrap for sandboxing (system services run in their own isolated namespaces).
Given how many products seem to be using this shipping-Linux-as-a-library-VM trick these days, it's probably a good time for an open source project to step up to supply a more reusable way of assembling this layer into a proper Mac library...
Maybe not easy or for everyone but you can set a Virtualbox VM running a headless linux of your choice, install directory sharing like samba and your AI agents of choice. Then you can just have multiple SSH sessions to interact with the agents and `tail` logs.
The Claude Code devcontainer works really well, especially the firewalling script! I had do a bit of GitHub Actions spelunking to figure out how to build binary images (with my own devtools preinstalled), which I wrote up here: https://anil.recoil.org/notes/ocaml-claude-dev
With this I have a nice loop where I get Claude to analyse its own sessions via a cronjob and rewrite my devcontainer Dockerfile to have any packages that I've started using during the interactive sessions. This rebuilds via GHActions and my fresh image the next day has an updated Claude and dev environment in a sandbox.
I mean, it depends on what you're doing but I force claude to always commit code every time it finishes a todo. It never seems to stop doing that, so I run it in dangerous mode on Zed. I get to review the code after the fact anyway.
The danger there is not that it commit bad things, but that as part of working the task it gets tricked into sending your env/secrets/credentials to prompt injectors. That would not show up in your commit diff.
Edit:
At the very least, I would not allow it to do indiscriminate web searching.
Is there an easy way to do something similar for Claude Code? I'm growing tired of babysitting it to make sure it doesn't do anything bad.
Late adopter. Started last night. Stayed up four hours past my normal bedtime because I couldn't stop.
Needed the Max 5x plan after two hours. (The 'Pro' plan should be renamed 'Sampler', made one-time and free with CC details.) Max 5x seems like it can sustain my current appetite.
I very quickly went from thinking it was overpriced (around 100 USD/month) to worrying that this pricing can't last. I think I get about 50 working hours per week with this plan.
Isn't the easy way just a development VM? As in:
Install your OS of choice in a virtual machine, e.g. even hosted on your main machine.
Install the AI coding tool in the virtual machine.
Set up a shared folder between host+guest OS.
Only let the VM access files that are "safe" for it to access. Its own repo, in its own folder.
If you want to give the AI tool and VM internet access and tool access, just limit what it can reach to things it is allowed to go haywire on. All the internet and all OS tools are ok. But don't let this AI do "real things" on "real platforms" -- limit the scope of what it "works on" to development assets.
When deploying to staging or prod, copy/sync files out of the shared folder that the AI develops on, and run them. But check them first for subterfuge.
So, don't give the AI access to "prod" configs/files/services/secrets, or general personal/work data, etc. Manage those in other "folders" entirely, not accessible by the development VM at all.
Is that close?
From within VSCode, you can run devcontainers, which bind mounts the project's directory into an isolated Docker container. Safe for --dangerously-skip-permissions
https://code.visualstudio.com/docs/devcontainers/containers
As a note, running devcontainers in VSCode is easy, but not required. There is also a CLI tool that uses the same specifications.
You can install it with brew or npm.
Tried this the other day and the setup on this is super cumbersome and requires you to constantly rebuild your entire dev and Claude Code environment every time you use a new container, including whitelisting URLs for package managers and the like.
There are techniques to mitigate this. You can reuse containers instead of creating a new one each time. You can mount in directories (like ~/.claude) from your local machine so you dont have to set claude up each time.
Docker desktop has a pretty nice sandbox feature that will also store your CC (and other) credentials, so you don't have to re-auth every time you create a new container.
Funnily enough, we shipped the Docker Desktop VM a decade ago now (experience report at https://dl.acm.org/doi/10.1145/3747525). The embedded VM in DD is much more stripped down than the one in Claude Cowork (its based on https://github.com/linuxkit/linuxkit), and its more specialised to container workloads rather than just using bubblewrap for sandboxing (system services run in their own isolated namespaces).
Given how many products seem to be using this shipping-Linux-as-a-library-VM trick these days, it's probably a good time for an open source project to step up to supply a more reusable way of assembling this layer into a proper Mac library...
Maybe not easy or for everyone but you can set a Virtualbox VM running a headless linux of your choice, install directory sharing like samba and your AI agents of choice. Then you can just have multiple SSH sessions to interact with the agents and `tail` logs.
Simon Willison just posted about using claude in fly.io's dev sandboxes. I have not tried it yet but it looks promising.
https://simonw.substack.com/p/first-impressions-of-claude-co...
Use a devcontainer. Claude Code's repo has one built specifically for it:
https://github.com/anthropics/claude-code/tree/main/.devcont...
The Claude Code devcontainer works really well, especially the firewalling script! I had do a bit of GitHub Actions spelunking to figure out how to build binary images (with my own devtools preinstalled), which I wrote up here: https://anil.recoil.org/notes/ocaml-claude-dev
With this I have a nice loop where I get Claude to analyse its own sessions via a cronjob and rewrite my devcontainer Dockerfile to have any packages that I've started using during the interactive sessions. This rebuilds via GHActions and my fresh image the next day has an updated Claude and dev environment in a sandbox.
Claude Code on web is okay in the meantime if you want to set it loose but not on your own machine.
/sandbox https://code.claude.com/docs/en/sandboxing
> The sandboxed bash tool uses OS-level primitives to enforce both filesystem and network isolation.
As I can't trust Claude Code to use a correct shell, I don't know why I would trust this feature.
I mean, it depends on what you're doing but I force claude to always commit code every time it finishes a todo. It never seems to stop doing that, so I run it in dangerous mode on Zed. I get to review the code after the fact anyway.
The risk isn’t that it makes weird commits; it’s that it may decide to clean up stuff and delete more than desired.
- https://github.com/anthropics/claude-code/issues/4331
- https://github.com/anthropics/claude-code/issues/7787
- https://news.ycombinator.com/item?id=46268222
The danger there is not that it commit bad things, but that as part of working the task it gets tricked into sending your env/secrets/credentials to prompt injectors. That would not show up in your commit diff.
Edit: At the very least, I would not allow it to do indiscriminate web searching.