Local coding agents are inherently unsafe, author argues
Author theahura argues that local coding agents like Claude Code force a fundamental tradeoff between autonomy, ease of setup, and security — and that cloud-based sandboxes are the only real solution.
Score breakdown
Practitioners running local coding agents should understand the concrete security tradeoffs — and the specific mitigations (`/sandbox`, deny rules for credential paths) and architectural alternatives (cloud-based Firecracker micro-VMs) described here.
- 01Author theahura runs Claude Code with `claude --dangerously-skip-permissions` ("YOLO mode") to avoid constant permission prompts.
- 02The post argues local coding agents face a trilemma: you can have powerful, easy, or secure — but only two at once.
- 03Anthropic data cited in the post: Claude Code users approve 93% of permission prompts.
In a post on 12 Grams of Carbon, theahura frames the core problem of local coding agents through a personal confession: they alias `claude` to `claude --dangerously-skip-permissions` to avoid the constant approval fatigue of permission prompts. This leads to the central thesis — that local coding agents like Claude Code and Codex present an unavoidable three-way tradeoff between being highly autonomous, easy to set up, and genuinely secure. In practice, only two of the three are achievable simultaneously. Most users, the post argues, land in the "powerful, easy, insecure" quadrant largely by choice, since setting up a proper secure sandbox is too complex for the average consumer.
The post's proposed solution is cloud-based sandbox environments built on Firecracker micro-VMs.
The post acknowledges several partial mitigations for local setups: enabling `/sandbox` (which uses bubblewrap on Linux and Seatbelt on macOS to confine writes to the working directory and route network traffic through an allowlist proxy), adding explicit deny rules for sensitive paths like `~/.ssh`, `~/.aws/credentials`, `.env`, `id_rsa`, `.npmrc`, and `~/.netrc`, and writing careful agent configs. Anthropic's own permission classifier work is cited — Claude Code users approve 93% of permission prompts, and Anthropic has shipped automated classifiers to reduce approval fatigue — but theahura dismisses all of these as bandaids, noting that basic file read/write access alone is sufficient to break most guardrails.
The post's proposed solution is cloud-based sandbox environments built on Firecracker micro-VMs. In this architecture, each agent session runs on a clean VM spun up from a setup script that clones repos and installs dependencies fresh. The VM holds no persistent state, so it can be destroyed without consequence. Critically, secrets are never stored on the same machine where the agent runs — instead, a proxy mediates between the agent runtime and the outside world. The post notes this approach also unlocks additional benefits beyond security, such as remote access and event-triggered agent execution.
Key facts
- 01Author theahura runs Claude Code with `claude --dangerously-skip-permissions` ("YOLO mode") to avoid constant permission prompts.
- 02The post argues local coding agents face a trilemma: you can have powerful, easy, or secure — but only two at once.
- 03Anthropic data cited in the post: Claude Code users approve 93% of permission prompts.
- 04Partial local mitigations include `/sandbox` (bubblewrap on Linux, Seatbelt on macOS), and explicit deny rules for paths like `~/.ssh` and `~/.aws/credentials`.
- 05The post argues basic file read/write access is enough to break out of most guardrails, making local mitigations fundamentally insufficient.
- 06The author's preferred solution is Firecracker micro-VM cloud sandboxes where each agent session starts clean and secrets are never stored on the agent's host machine.
Topics
Summary and scoring are generated automatically from the original article. We always link back to the publisher and never republish images or paywalled content. Last processed Jun 7, 2026 · 12:45 UTC. How this works →