Earlier quoted context omitted.
It's the default behaviour for Vagrant. You put a Vagrantfile in your repo, run `vagrant up` and it creates a VM with the repo folder shared r+w to `/vagrant` in the VM.
That's because Vagrant isn't "VM", it's a developer tool you use locally that happens to use VMs, and it was created in a era where 1) containers didn't exist as they do today, 2) packaging and distribution for major languages wasn't infected with malware and 3) LLM agents now runs on our computers and they are kind of dumb sometimes and delete stuff. With new realities, new workflows have to be adopted. Once malware…
Running Claude Code dangerously (safely)
241–250 of 265 posts
Re: Running Claude Code dangerously (safely)
#242Earlier quoted context omitted.
For Windows a quick win is to install VMware Workstation Pro (which is free) and install Ubuntu 24.04 LTS as a VM. Broadcom bought VMware then released Workstation Pro for free and I don't think they kept the download link but you can get from TechPowerUp: https://www.techpowerup.com/download/vmware-workstation-pro/ You can then let LLMs on YOLO mode inside it.
What is the advantage of using VMware Workstation Pro for this as opposed to using WSL2?
Re: Running Claude Code dangerously (safely)
#243Earlier quoted context omitted.
Or just a VM that doesn't share so much with your host. Just makes for a more annoying dev experience.
Why do you need to share anything? Code goes through GitHub - VM has it's own repo clone, if you need data files, you mount them read-only in the VM, have a read-write mount for output data.
Re: Running Claude Code dangerously (safely)
#244Earlier quoted context omitted.
I totally agree with you. Running a cheapo mac mini with full permissions with fully tracked code and no other files of importance is so liberating. Pair that with tailscale, and being able to ssh/screen control at any time, as well as access my dev deployments remotely. :chefs kiss:
why a mac mini rather than a cloud vps
Re: Running Claude Code dangerously (safely)
#245I use Development containers (dev-containers) as demonstrated by Claude Code's docs https://code.claude.com/docs/en/devcontainer It all integrates nicely with VS Code. It has a firewall script and you spin up your database within the docker compose file so it has full access to a postgres instance. I can share my full setup if anyone needs it.
This would be lovely and much appreciated! Devcontainers look perfect but also like a bit of a burden to entry with regards to setup.
Re: Running Claude Code dangerously (safely)
#246Earlier quoted context omitted.
This would be lovely and much appreciated! Devcontainers look perfect but also like a bit of a burden to entry with regards to setup.
Here is the setup I use. It installs Python, uv, Claude Code, npm, and pnpm. Tested in VS Code and Cursor. https://davidbern.com/blog/2026/claude-code-dev-containers/
Re: Running Claude Code dangerously (safely)
#247What is the consensus on Claude Code's built-in sandboxing? https://code.claude.com/docs/en/sandboxing#sandboxing > Claude Code includes an intentional escape hatch mechanism that allows commands to run outside the sandbox when necessary. When a command fails due to sandbox restrictions (such as network connectivity issues or incompatible tools), Claude is prompted to analyze the failure and may retry the command wit…
Re: Running Claude Code dangerously (safely)
#248I just gave it its own user and dir. So I can read and write /agent, but agents can't read or write my homedir. So I just run agents as the agent user. I don't need it to have root though. It just installs everything locally. If I did need root I'd probably just buy a used NUC for $100, and let Claude have the whole box. I did something similar by just renting a $3 VPS, and getting Claude root there. It sounds bad bu…
Re: Running Claude Code dangerously (safely)
#249It's impossible to not get decision-fatique and just mash enter anyway after a couple of months with Claude not messing anything important up, so a sandboxed approach in YOLO mode feels much safer. It takes the stress about needing to monitor all the agents all the time too, which is great and creates incentives to learn how to build longer tasks for CC with more feedback loops. I'm on Ubuntu 22.04 and it was surpris…
I've been working for the past several weeks in an environment where it's easy and safe to give different claudes yolo-mode, but yesterday I needed to build an Emacs TRAMP plugin, and I had to do that on my local development NUC. I am extremely spoiled for yolo-mode, because even just yes-ok'ing all the elisp fragments claude came up with was exasperating, the whole experience was draining, and that was me not being…
Re: Running Claude Code dangerously (safely)
#250It's impossible to not get decision-fatique and just mash enter anyway after a couple of months with Claude not messing anything important up, so a sandboxed approach in YOLO mode feels much safer. It takes the stress about needing to monitor all the agents all the time too, which is great and creates incentives to learn how to build longer tasks for CC with more feedback loops. I'm on Ubuntu 22.04 and it was surpris…
I'm currently stuck on Windows, but I thought sandboxing was built in to Claude Code as a feature on Linux with the /sandbox command?
It's still experimental and if you dive into the issues I would call its protection light. Many users experiences erratic issues with perms not being enforced, etc.
For me the largest limitation was that it's read-mode is deny-only, meaning that with an empty deny-list it can read all files on your laptop.
Restricting to specific domains have worked fine for me, but it can't block on specific ports, so you can't say for instance you may access these dev-server ports, but not dev-server ports belonging to another sandbox.
It feels as though the primary usecase is running inside an already network and filesystem sandboxed container.