I let Claude Code run wild in a virtual machine, and it changed how I use auto mode

Published Sep 8, 2026, 6:00 AM EDT Anurag is an experienced journalist and author who’s been covering tech for the past 5 years, with a focus on Windows, Android, and Apple. He’s written for sites like Android Police, Neowin, Dexerto, and MakeTechEasier. Anurag’s always pumped about tech and loves getting his hands on the latest gadgets. When he's not procrastinating, you’ll probably find him catching the newest movies in theaters or scrolling through Twitter from his bed. I think that when you have to give an autonomous tool permission to do something, it often kills the autonomy. We often see that with Claude Code. You ask the agent to do something, and it starts working on the task, but during the process it also asks for permission to run certain commands, which means you have to keep approving them. I don’t think there is really an alternative to reviewing those commands. You should be doing that because otherwise you risk losing important data in the project, and it could potentially lead to something worse. Claude Code does have an auto mode, but should you trust it with your important data? I don’t think so. What I like to do instead is run Claude Code inside a virtual machine and then give its auto mode free rein. That saves a lot of time while also giving the agent room to do whatever it needs to do. VM creates the boundary You can just let Claude Code loose inside a VM Claude Code needs access to files and terminal commands to complete coding tasks. Those capabilities are useful, but they are also why I don’t want to give auto mode unrestricted access to my main computer. Even with Claude Code’s built-in safety checks, it would still be working in an environment that contains my personal files, other projects, and applications. I am using a virtual machine to give Claude Code a separate operating system and filesystem. The VM only contains the project I want the agent to work on, along with Git, Claude Code, and the dependencies required by that project. It doesn’t have access to the rest of my computer unless I deliberately share a folder or another resource with it. You need to keep that separation intact for the setup to make sense. If you mount your main project folder directly inside the VM, Claude Code can still change or delete the original 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 VM doesn’t need every API key and account stored on the host. I only add what the project requires. For the VM itself, I am using VirtualBox with Ubuntu as the guest operating system. I assigned it two CPU cores and 4GB of RAM, then installed Claude Code and the development tools required by the project inside Ubuntu. Auto mode lets Claude Code keep working And you don't have to worry about things going wrong The main difference with this setup is when I review Claude Code’s work. In its regular permission mode, the review happens while the agent is working because it stops and asks before running certain commands. Inside the virtual machine, I can switch to auto mode and let Claude continue without waiting for me at every step. Auto mode still uses a separate classifier to review actions in the background, so it isn’t the same as completely disabling the permission system. However, it removes most of the interruptions that make longer tasks difficult to leave unattended. Claude can edit files, run tests, use routine terminal commands, and respond to errors while I do something else. Once the task is complete, I still review everything before moving it out of the virtual machine. I check the Git diff to see which files Claude changed and whether it touched anything outside the scope of the task. I also run the project and its tests inside the VM instead of assuming that a completed task means the code works. When the changes look good, I can move them back by creating a Git commit, pushing them to a separate branch, or copying only the files I want. Claude Code’s own sandbox is also useful But it's not a VM Claude Code also has a built-in sandbox, so a virtual machine isn't the only way to set boundaries around the agent. The sandbox can restrict the filesystem and network access available to Bash commands, making it harder for Claude to access files or services outside the areas you have allowed. That’s still better than giving Claude Code broad access to your computer, but I would not treat the sandbox as 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 configure. Your project files and any additional paths you allow remain accessible to the agent. A VM provides better separation because Claude Code runs inside a separate operating system with its own virtual disk. Given how powerful these agents have become and how often they manage to escape sandboxes and even hack other companies, you should take additional precautions. You can also consider a deny list for Claude Code You can also create a deny list to block actions that Claude Code should never be allowed to perform. Its permission settings let you deny specific tools, commands, and file paths, so you can prevent the agent from running destructive commands, accessing credentials, or touching folders outside the project.