Sandboxing, and why it’s the juicy part
Today we make YOLO safe. “Sandboxing” sounds like dry security homework — but it unlocks the most exciting super-power in the whole course: letting Claude run wild while nothing it does can hurt you. Let’s see why, and map out the three ways to do it.
Yesterday was a feast — the full pro toolkit. If you felt a little overwhelmed, that is completely normal, and it is exactly the reaction Andrej Karpathy captured in his famous tweet about the dizzying number of options. So before the new material, take a breath: you do not need all of it every day.
01Where we are (a quick recap)
Here is the honest, de-stressed version of the pro toolkit you already learned:
Skills
These have become the universal standard — Anthropic invented them, but Codex, OpenCode and others all use them now. Slash-commands are largely replaced by skills.
Sub-agents
Delegate a task to an isolated context and get back only the result. The main reason to use one is to protect your context window.
Hooks
Reach for these only when you have a specific problem to solve. Now you know they exist and where the docs are.
Plugins & marketplaces
Handy for packaging skills/agents to share with a team. Not an everyday thing.
A plugin folder can also carry .mcp.json (MCP servers it ships with) and .lsp.json — a Language Server Protocol config. LSP teaches Claude Code the rules of a programming language so it can validate the code it writes. Claude already knows the common languages; you would only add an .lsp.json to support an exotic one. You will almost certainly never need it — but now, when you re-read that tweet, you will nod along to every line.
Actually do the exercises once: create a slash-command, a sub-agent, a hook, and package a tiny plugin. Going through the motions once turns “I read about it” into “I can do it”.
02What “sandboxing” really means
A sandbox is a ring-fence around what an agent is allowed to touch. You tell it, in effect: “go wild inside this box — read, write, run scripts to your heart’s content — but you cannot reach outside it.” Two fences matter most:
The pay-off is not only security — it is productivity. Because the box is safe, you can happily run at a “YOLO” level of freedom without taking a real risk. You become willing to let Claude just go.
Remember last week, when we said “maybe wait until we have sandboxing before you truly YOLO”? This is that moment. Now we can.
03The hidden win: beating approval fatigue
In an un-sandboxed world, Claude asks permission for risky actions and you press 2 to approve (or 1 to go step-by-step). Sounds safe. But there is a trap.
After the tenth prompt, your brain stops reading. You just tap 1…1…1…1 on autopilot. This is approval fatigue, and it means the “safe” un-sandboxed workflow can be less safe than it feels — you are rubber-stamping things you never truly checked.
A sandbox flips this around. Inside the box, actions are auto-approved because they are already safe — so there is nothing to rubber-stamp. You get the speed of YOLO and a genuine safety net, instead of a fake one. That is the third, best flavour: secure and productive at once.
04The three ways to sandbox
The rest of today is three techniques. The instructor colour-codes them — keep this map in your head, because it is easy to get lost otherwise:
Native sandbox
Built into Claude Code. Type /sandbox. A lightweight, OS-level box running on your machine. (13.2)
Claude Code on the Web
Anthropic runs Claude for you in a cloud sandbox — browser, mobile, terminal, or a GitHub issue. (13.3)
Third-party sandbox
Another company (e.g. Sprites.dev by fly.io) gives you a cloud box built for coding agents. (13.4)
Blue = your own lightweight Docker, on your laptop. Purple = “Claude, go run this somewhere else” on Anthropic’s machines. Yellow = rent a fast, isolated Linux box from a specialist and run any agent in it.
05A word on Docker & dev-containers
If you already know Docker (or VS Code’s .devcontainers), you know the original way to get a “box within a box”. That still works and you can always use it. But everything today takes it a step further — the native sandbox is lighter than Docker, and the cloud options add remote execution on top. So think of Docker as the baseline we are now improving on, not something you must set up first.
✓ Key takeaways
- A sandbox ring-fences the file system and the network so an agent can run freely without real risk.
- The real prize is safe productivity — it cures approval fatigue (the 1-1-1-1 autopilot).
- Three approaches: Blue native/local, Purple managed cloud, Yellow third-party cloud.
- Docker/dev-containers still work — today we go beyond them.