posts · 2026-07-20

This piece walks through a full bug-fix task—clone, npm install, edit, test, push—and uses it to explain why approval gates, command blacklists, and dedicated tools each miss what happens after a command starts. The useful framing: risks come from three places (model mistakes, prompt injection from external content, and third-party dependency scripts), and OS isolation handles all of them by limiting file and network access at the process level, without needing to know which source caused the problem. Two things I'd flag. First, the distinction between "VM protects the host but not legitimate credentials" is well drawn: network policy controls destinations, credential proxying keeps raw tokens out of the sandbox, and external permission policy limits what a valid identity can do remotely. These three layers don't replace each other. Second, the article notes that workspace isolation lets you discard bad changes before they hit a shared branch—snapshots and git diff act as checkpoints, not security boundaries. No performance numbers or latency figures here; this isn't a benchmark. It reads more like a security map for developers who already click "allow in sandbox" daily in Cursor or Claude Code but haven't thought through why. Worth ten minutes if that's you.