There are two spheres of influence you need to consider. The local machine/vm/container that the agent is running in. But also the effect the agent can have on the outside world - using auth tokens or ssh keys or apis that is has access to. This article largely deals with the first problem and ignores the second.
You can have the local environment completely isolated with vagrant. But if you’re not careful with auth tokens it can (and eventually will when it gets confused)go wipe the shared dev database or the GitHub repo. The author kinda acknowledges this, but it’s glossing over a big chunk of the problem. If it can pus to GitHub, unless you’ve set up your tokens carefully it can delete things too. Having a local isolated test database separate from the shared infrastructure is a matter of a mature dev environment, which is a completely separate thing from how you run Claude. Two of the three examples cited as “no, no, no” are not protected by vagrant or docker or even EC2. It’s what tokens the agent has and needs.
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.