Comparison to sandbox mode: yolo still needed?

yolo self-generated report: Sandbox vs. YOLO: A Comparison

Both solve the same fundamental problem — **how to let Claude Code run autonomously without it doing something dangerous** — but they take very different architectural approaches.

## Core Philosophy

| | Claude Code Sandbox | YOLO |
|---|---|---|
| **Approach** | Fine-grained OS-level policy enforcement | Coarse-grained container isolation |
| **Metaphor** | "You can run freely, but these specific walls are enforced by the kernel" | "You're in a separate room; do whatever you want in there" |
| **Permission model** | Whitelist domains + filesystem paths, deny everything else | Mount only what's needed, auto-approve everything inside |
| **Technology** | macOS Seatbelt / Linux Bubblewrap + network proxy | Podman rootless containers + user namespaces |

## What Each Restricts

| Resource | Claude Code Sandbox | YOLO |
|---|---|---|
| **Filesystem write** | CWD only (configurable allowlist) | Only mounted volumes (CWD, `~/.claude`, `.gitconfig`) |
| **Filesystem read** | Whole machine minus denylist | Only mounted volumes |
| **Network** | Proxy-based domain allowlist | **Unrestricted** (intentional) |
| **SSH keys** | Accessible (unless denied) | **Not mounted** (no git push) |
| **Subprocess isolation** | All children inherit sandbox | All children are in the container |
| **Credentials** | Configurable deny (e.g., `~/.aws/credentials`) | Only OAuth token passed via env var |

## Key Trade-offs

### Claude Code Sandbox strengths

- **Network filtering** — the biggest differentiator. YOLO has no network restrictions, meaning a prompt injection attack could exfiltrate data. The sandbox's domain-level proxy blocks this.
- **No setup overhead** — no container build step, no image maintenance. Just `bubblewrap` + `socat` on Linux.
- **Full host read access by default** — Claude can read your whole machine (minus denylists), which is useful for cross-project work.
- **Granular configurability** — per-path, per-domain rules in `settings.json`.
- **Open-source runtime** — `@anthropic-ai/sandbox-runtime` is reusable in other agent projects.

### YOLO strengths

- **Stronger filesystem isolation** — sandbox allows reading the whole machine by default; YOLO only exposes what you mount. A read-based side-channel attack is harder.
- **Reproducible environment** — the Dockerfile gives you a known, consistent toolchain (git, gh, shellcheck, uv, etc.). No "works on my machine" issues.
- **Customizable environments** — NVIDIA GPU support, Playwright, DataLad, jj via `--extras`. The sandbox doesn't manage your tool environment.
- **Session portability** — preserved paths mean sessions work identically in and out of the container.
- **Config layering** — user-wide + per-project config with array merging for volumes/args.
- **No SSH key exposure** — a deliberate security boundary that forces push operations to happen on the host.

## Where YOLO Has a Gap

The **network** is the elephant in the room. YOLO's container has unrestricted network access. This means:

- A prompt injection in a code comment could instruct Claude to `curl` data to an attacker's server
- Malicious dependencies could phone home
- There's no domain allowlisting

The sandbox's proxy-based network filtering directly addresses this threat model.

## Where Claude Code Sandbox Has a Gap

- **No environment management** — you're running on your host. If Claude needs `playwright` or `cuda`, it's installing on your machine.
- **Read access is broad by default** — `~/.ssh`, `~/.gnupg`, env files, etc. are readable unless you explicitly deny them. YOLO's mount-only approach is deny-by-default for the filesystem.
- **Platform limitations** — no native Windows support, weaker in nested Docker environments on Linux.

## Could They Be Combined?

Yes, and it would be the strongest posture:

1. **YOLO for environment isolation** — reproducible toolchain, mount-only filesystem, no SSH keys
2. **Claude Code sandbox inside the container** — add network filtering and filesystem write restrictions within the already-restricted container

This would give you defense-in-depth: container boundaries for the coarse isolation + sandbox policies for fine-grained network and filesystem control inside.

## Summary

If your primary threat model is **"Claude modifies the wrong files or installs something I don't want"**, both approaches work well.

If your threat model includes **"data exfiltration via network"**, the Claude Code sandbox is strictly better today — YOLO would need network restrictions (e.g., podman `--network=none` plus an allowlist proxy, or just enabling sandbox mode inside the container).

If your concern is **reproducible, portable environments with known toolchains**, YOLO provides something the sandbox doesn't attempt.

They're complementary rather than competing.

tldr;

sandbox: You can run freely, but these specific walls are enforced by the kernel
- Global Read: Whole machine minus denylist
- Limited Write
- network protection

yolo: You're in a separate room; do whatever you want in there
- Read: Mount only what's needed, auto-approve everything inside
- no network protection

IMO, global read with deny list is insufficient for `--dangerously-bypass-permissions`. I will not be using sandbox mode. So I think that `yolo` continues to be worth some time and effort to maintain/improve. @yarikoptic feel free to close if satisfied.