I let Claude Code run in a virtual machine and it changed the way I use automatic mode.

I think when you have to give an autonomous tool permission to do something, it often kills autonomy. We see this a lot with Claude Code. You ask an agent to do something and it starts working on the task, but in the process it also asks for permission to execute certain commands, which means you have to constantly approve them.

I don’t think there is an alternative to watching these commands. You should do this because otherwise you risk losing important data in the project and it could potentially lead to something worse.

Claude Code has an automatic mode, but should you trust it with important data? I don’t think so. Instead, I prefer to run Claude Code in a virtual machine and then give it free rein in unattended mode. This saves a lot of time and also gives the agent the freedom to do whatever they need to do.

VM creates border

You can simply let Claude Code run freely inside the virtual machine.

Claude Code requires access to files and terminal commands to perform coding tasks. These features are useful, but that’s why I don’t want to give the automatic mode unlimited access to my main computer. Even with Claude Code’s built-in security checks, it will still work in an environment containing my personal files, other projects, and applications.

I’m using a virtual machine to give Claude Code a separate operating system and file system. The virtual machine contains only the project that the agent should work on, as well as the Git, Claude Code, and dependencies required for that project. He doesn’t have access to the rest of my computer unless I intentionally share a folder or other resource with him.

You need to keep this separation intact for the installation to make sense. If you mount the main project folder directly inside the virtual machine, Claude Code will still be able to modify or delete the source files. I keep a separate copy of the project inside the virtual machine and avoid sharing directories that contain anything important.

The same applies to credentials. Claude Code may need access to GitHub or another service, but the virtual machine does not need all the API keys and accounts stored on the host. I only add what the project requires.

For the virtual machine itself, I use VirtualBox with Ubuntu as the guest operating system. I allocated two CPU cores and 4GB of RAM to it, then installed Claude Code and the development tools needed for the project in Ubuntu.

Automatic mode allows Claude Code to continue working

And you don’t have to worry about anything going wrong

The main difference in this attitude emerges when I look at the work of Claude Code. In normal permission mode, checking occurs while the agent is running because it stops and prompts before executing certain commands. Inside the virtual machine, I can switch to automatic mode and let Claude continue without having to wait for me every step of the way.

Automatic mode still uses a separate classifier to check for background activity, so it’s not the same as disabling the permissions system entirely. However, it eliminates most of the interruptions that make it difficult to leave longer tasks unattended. Claude can edit files, run tests, use standard terminal commands, and respond to errors while I do something else.

After the task is completed, I still check everything before I take it out of the virtual machine. I check the difference in Git to see what files Claude changed and if it affected anything outside the scope of the task. I also run the project and its tests inside a virtual machine instead of assuming that completion of the task means the code is working. When the changes look good, I can push them back by making a Git commit, pushing them to a separate branch, or copying only the files I need.

Claude Code’s own sandbox is also useful.

But this is not a virtual machine

Claude Code also has a built-in sandbox, so a virtual machine isn’t the only way to set boundaries around an agent. Sandboxing can restrict the file system and network access available to Bash commands, making it difficult for Claude to access files or services outside of the areas you allow.

It’s still better than giving Claude Code wide access to your computer, but I wouldn’t consider sandboxing a replacement for a virtual machine. Claude Code still runs on your main operating system, and the sandbox only controls what it can access within the boundaries you’ve configured. Your project files and any additional paths you enable remain available to the agent.

A virtual machine provides better separation because Claude Code runs inside a separate operating system with its own virtual disk. Considering how powerful these agents have become and how often they manage to escape sandboxes and even hack other companies, you should take extra precautions.

You may also want to consider the list of prohibitions for Claude Code.

You can also create a prohibited actions list to block actions that Claude Code should never be allowed to perform. Its permission settings allow you to deny certain tools, commands, and file paths, so you can prevent the agent from executing destructive commands, accessing credentials, or touching folders outside of the project.