Hmm, perhaps I'm missing something, so let's go through it step by step and see where the disconnect is:
- There's a cloned 'my-project' git repo on the base OS
- The 'Vagrantfile' is added to the project
- 'vagrant up', 'vagrant ssh' and claude login is run inside the VM
At this stage, besides the source code and the Claude Code token (after logging in), there are no other credentials on the VM: no SSH keys, no DB credentials, no API tokens, nothing.
There is also no need to add:
- SSH keys or GitHub tokens: because git push/pull is handled outside the VM
- DB credentials: because Claude can just install a DB inside the VM and run the project migrations against that isolated instance, not any shared/production database
API tokens can definitely be a problem if you need external service integration. But that's an explicit opt-in decision, you'd have to deliberately add those credentials to the Vagrantfile or sync them in. At that point, yes, you need proper token scoping and permissions.
Integration tests are where it breaks down. Assuming Claude can just install whatever infrastructure it needs inside the VM only works for relatively simple projects. Claude probably isn’t going to install a Kafka queue in your VM. Or a k8 cluster. Maybe it could. But unless you’re in a monorepo it wouldn’t know how to configure it properly.
> Mounting the Docker socket grants the agent full access to your Docker daemon, which has root-level privileges on your system. The agent can start or stop any container, access volumes, and potentially escape the sandbox. Only use this option when you fully trust the code the agent is working with.
We have an updated version of Sandboxes coming out soon that uses MicroVM isolation to solve this exact problem. This next version will let your agent access a Docker instance within the MicroVM, therefore allowing you to do this securely.
I tried this approach for a while, but I really wanted it to be able to do anything (install system packages, build/run Docker containers, the works).
With these powers there's a lot less back-and-forth with me running commands, copying the output, pasting it to Claude, etc.
I'm sure you've had the case where you had to instruct someone to do something (e.g. playing tech support with family, helping another engineer, etc). While it helps the other person learn, it feels soooo slow vs just doing it yourself :) And since I don't have to teach the agent, I think this approach makes sense.
This was also the direction I was initially headed, but then I realized I wanted one-VM-per-project so it can really do anything it wants on the complete VM. So the blast-from-the-past-Vagrant won because of the Vagrantfile + `vagrant up` easiness.
It's been ages since I used VirtualBox and reading the following didn't make me miss the experience at all:
> Eventually I found this GitHub issue. VirtualBox 7.2.4 shipped with a regression that causes high CPU usage on idle guests.
The list of viable hypervisors for running VMs with 3D acceleration is probably short but I'd hope there are more options these days for running headless VMs. Incus (on Linux hosts) and Lima come to mind and both are alternatives to Vagrant as well.
I totally understand, Vagrant and VirtualBox are quite a blast from the past for me as well. But besides the what-are-the-odds bug, it's been smooth sailing.
> VMs with 3D acceleration
I think we don't even need 3D acceleration since Vagrant is running the VMs headless anyways and just ssh-ing in.
> Incus (on Linux hosts)
That looks interesting, though from a quick search it doesn't seem to have a "Vagrantfile" equivalent (is that correct?), but I guess a good old shell script could replace that, even if imperative can be more annoying than declarative.
And since it seems to have a full-VM mode, docker would also work without exposing the host docker socket.
Thanks for the tip, it looks promising, I need to try it out!
Depends on what you do. If you need to have a fully working site with external integrations, SSL and so on, it's just easier to spend $4 a month on a VPS. But you're right, for many backend-based projects a local VM like multipass or a kind/microk8s cluster are perfectly fine.
You mentioned "deleting the actual project, since the file sync is two-way", my solution (in agentastic.dev) was to fist copy the code with git-worktree, then share that with the container.
Good point. For me, that was intentional, since all my projects are in git I don't care if it messes something up. Then you get the benefit of being able to use your regular git tooling/flows/whatever, without having to add credentials to the VM.
But if you need something more strict, 'config.vm.synced_folder' also supports 'type rsync', which will copy the source folder at startup to the VM, but then it's on you to sync it back or whatever.
Since Android 15, Google Pixel phones have a "notification cooldown" that sort of fixes this. Hopefully it makes it's way to all Android phones at some point.
- There's a cloned 'my-project' git repo on the base OS
- The 'Vagrantfile' is added to the project
- 'vagrant up', 'vagrant ssh' and claude login is run inside the VM
At this stage, besides the source code and the Claude Code token (after logging in), there are no other credentials on the VM: no SSH keys, no DB credentials, no API tokens, nothing.
There is also no need to add:
- SSH keys or GitHub tokens: because git push/pull is handled outside the VM
- DB credentials: because Claude can just install a DB inside the VM and run the project migrations against that isolated instance, not any shared/production database
API tokens can definitely be a problem if you need external service integration. But that's an explicit opt-in decision, you'd have to deliberately add those credentials to the Vagrantfile or sync them in. At that point, yes, you need proper token scoping and permissions.
reply