[runekaagaard]

It'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 surprisingly pleasant to create a layered sandbox approach with bubblewrap and Landlock LSM: Landlock for filesystem restrictions (deny-first, only whitelisted paths accessible) and TCP port control (API, git, local dev servers), bubblewrap for mount namespace isolation (/tmp per-project, hiding secrets), and dnsmasq for DNS whitelisting (only essential domains resolve - everything else gets NXDOMAIN).

[tptacek]

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 especially careful (just making sure it didn't run random bash commands to, like, install a different Emacs or something).

[runekaagaard]

Configuring Claude Code ... the new init.el ;)

[runekaagaard]

... also interested. What would one build an Emacs TRAMP plugin for? :)

[tptacek]

Directly editing files on a remote VM that happens to have an API for directly accessing files.

[Nition]

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?

[hu3]

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.

[dragonwriter]

What is the advantage of using VMware Workstation Pro for this as opposed to using WSL2?

[TheTaytay]

I think it has default access to your c drive via a mount, for one. You could add layers/sandboxes, but it’s not isolated.

[tracker1]

Funny, but I wrote some environment initialization and setup scripts that you just unzip to a new dev desktop, and run the first powershell script, and it will work through (have to reboot after a couple installs), but it goes through, then once WSL is up, it'll rely on the /mnt/c/ paths to run bash scripts to initialize the wsl environment too... was pretty handy.

[dragonwriter]

Yeah, I do most Linux stuff on Windows in containers using podman leveraging WSL2, but that's a good point.

[bt1a]

I wouldn't put it past Opus 4.5 in yolo mode to vm escape if it felt like it haha

[UltraSane]

Stronger isolation and choice of OS

[Tossrock]

Windows has the WSL for native Linux vms, these days (and also the past ~decade)

[hu3]

I can rm -rf Windows files from WSL2. And so can LLMs.

Meanwhile a VM isolates by default.

[jassmith87]

You can turn all the interop and mounting of the windows FS with ease. I run claude in yolo mode using this exact setup. Just role out a new WSL env for each claude I want yoloing and away it goes. I suppose we could try to theorize how this is still dangerous buts its getting into extremely silly territory.

[hu3]

That's great to know! And important to clarify because by default WSL has access to all disks.

[runekaagaard]

/sandbox AFAIK uses https://github.com/anthropic-experimental/sandbox-runtime under the hood.

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.

[cedws]

It’s pretty weak sandboxing. It still grants full read only access to the file system so any secrets in your home directory can still be exfiltrated. I’m pretty sure it could also be deceptive and use a script to write where it shouldn’t be able to as well. That’s not really sandboxing in my opinion. It should be something like unveil, the process gets a working space at startup, and it cannot ever do anything outside of that directory.