Stephan Schmidt - July 3, 2026

How to Run Claude Code in YOLO Mode Without Losing Your Credentials

Sandbox Claude Code in a devcontainer: YOLO speed without handing the agent your credentials

Last week I counted. Over the course of a single afternoon session, I clicked “yes” in Claude Code over one hundred times. Yes, write this file. Yes, run this command. Yes, create this directory. And then there are three Claude Code CLIs running in three tmux panes at the same time. At some point you stop reading what you’re approving and just select yes . The EULA effect. Danger, Will Robinson!

YOLO mode does exist in Claude for a reason. Let Claude do the work without asking permission for every mkdir. But: Claude Code, running on your machine, can access everything and do everything over the next several hours until you look again. Most developers I talk to pick one of two bad options. Either they run YOLO and trust the AI (brave, stupid, pick one), or they keep clicking yes a hundred times a day. (I don’t want to give advice here, but AI is the Wild West and more YOLO is needed.)

There is a third option, which is running Claude Code in a devcontainer (with tradeoffs, there are always tradeoffs).

Anthropic meanwhile has a middle path of its own: auto mode (a research preview, so expect it to change). Instead of you clicking yes a hundred times, a second model watches every action Claude wants to take and decides allow, block, or ask - edits in the project go through, dependencies install from lock files, while curl | bash, force pushes and production deploys get blocked, and everything unclear gets judged from your conversation context. It even reads your .env and sends the right credential to the right API on its own, which is convenient, and which also means the agent handles your credentials.

But auto mode is a permission layer, and the agent still runs on your machine. The classifier decides what Claude may do, the operating system decides what Claude can do, and by default that includes reading ~/.ssh, your AWS credentials and your shell history, with every environment variable inherited into every command. Claude Code ships OS sandboxing too (Seatbelt on macOS, bubblewrap on Linux) and you can deny reads on credential files with sandbox rules - but now you are hand-writing security configuration again, per project, per machine. Auto mode fixes the hundred clicks. The blast radius is still yours.

I think in terms of hard guards and soft guards. Hard guards are guards that prevent an agent from doing something, like a devcontainer. And soft guards, which might break or the agents might break out from. Don’t confuse them, both are useful, and both are needed.

The AI-jail landscape

So I did take a look at the vast AI-jail landscape recently.

The simple wrappers – Bubblewrap, Landrun, Claude Sandbox on macOS – they work the way chroot jails worked twenty years ago. Restrict what the process can see and limit what it can touch. Bubblewrap can kill network access with --unshare-net, which is nice. Landrun only controls TCP port binding. Claude Sandbox on macOS restricts file writes. Then there’s Anthropic’s own Sandbox Runtime. HTTP/SOCKS5 proxy with domain rules, filesystem deny-read/write controls. But again no credential injection, no MITM proxying.

None of them can hide secrets from the AI, inject credentials where they’re needed, or audit what goes in and out. You can lock things down, file access at least, but you’re doing it manually, and the configuration is fiddly enough that you’ll probably get it wrong.

The ambitious tools are more interesting and more frustrating. Sandcat uses Docker Compose with WireGuard and a MITM proxy – it intercepts all traffic, substitutes secrets at the proxy level, enforces domain whitelists. On paper, this is exactly what you want (except lacking secret hiding). Matchlock runs Firecracker microVMs on Linux and uses Apple’s Virtualization framework on macOS. Agent-sandbox does MITM proxying with domain filtering and secret redaction.

The platform vendors are here too. Docker ships Docker Sandboxes – sbx run claude starts Claude in a microVM with its own Docker daemon, filesystem and network, your workspace mounted in, and if you want centrally managed network and filesystem policies, that part sits behind the paid Admin Console. Cloudflare Sandboxes runs agents in containers that start in milliseconds from standard images, aimed at agents and code interpreters living in their cloud. And Fly.io built Sprites – a persistent Firecracker microVM per agent, domain allow/deny lists for egress, checkpoint and restore of the whole filesystem in 300ms, billed by the hour (their own example prices a Claude Code session at $0.44).

A microVM beats a namespace, so the isolation here is a hard guard, better than anything the wrappers do.

Why dev containers won

With devcontainers you get a .devcontainer/devcontainer.json in your project, open it with the Dev Containers extension, and you’re inside a container. After that initial setup, every project with a devcontainer config just works.

Dev containers solve more problems than just YOLO. New developer joins the team? They open the project and they’re ready with devcontainers. No “install this version of Node, set up this database, configure this environment variable” ritual.

Customization annoyed me though. You want tmux in your container? (I NEED TMUX!) Edit the Dockerfile. You want ripgrep, fd, fzf, mdq – the tools Claude Code actually needs to be more productive? Edit the Dockerfile. You want a Go language server for LSP support? Edit the Dockerfile, install GVM, install gopls, hope it all works together. You’re happy and distribute the container in your team.

Now the maintainer of that dev container pushes an update. Your Dockerfile modifications? Gone. You’re back to hand-merging Dockerfile fragments.

What I use today

My own tool. I’m building human, a dev rig for Claude Code, and it grew a sandbox because I needed one: an isolated devcontainer with an outbound firewall and a secret-redacting filesystem, where human runs as a daemon on the host and forwards commands from inside the container - credentials stay on the host, resolved from a vault, and the agent never sees a token. The two things I complained about above, hiding secrets from the AI and injecting credentials where they’re needed, are the two things it does. (Yes, it’s my tool, judge my bias accordingly - I built it because everything else stopped one step short.)

The teams I work with use Anthropic’s container. And for non-interactive one-shot prompts - a cron job that triages tickets, a build step that writes the changelog - a full devcontainer is too much ceremony, a thin jail like Landrun that just cuts off filesystem and network is probably the right size there.

None of this is finished. Half the tools I listed will be gone or merged into Claude Code itself by next summer, and I expect to rebuild this setup twice before it settles. Doesn’t matter. Clicking yes a hundred times a day trains you to approve blindly, with your credentials in reach of the agent (the EULA effect again). Put the agent in a box, give it YOLO inside the box, and let it work for hours while you do something else. That was the point of agents all along.