19:I[1089,["311","static/chunks/311-efce64e8edbdd5cc.js","636","static/chunks/636-130e1bb21298e760.js","724","static/chunks/app/learn/ai-from-scratch/phases/%5BphaseSlug%5D/lessons/%5BlessonSlug%5D/page-5cf352d0b1b04425.js"],"LessonBody"] 1d:I[4365,["311","static/chunks/311-efce64e8edbdd5cc.js","636","static/chunks/636-130e1bb21298e760.js","724","static/chunks/app/learn/ai-from-scratch/phases/%5BphaseSlug%5D/lessons/%5BlessonSlug%5D/page-5cf352d0b1b04425.js"],"LessonProgressControls"] 1e:I[1089,["311","static/chunks/311-efce64e8edbdd5cc.js","636","static/chunks/636-130e1bb21298e760.js","724","static/chunks/app/learn/ai-from-scratch/phases/%5BphaseSlug%5D/lessons/%5BlessonSlug%5D/page-5cf352d0b1b04425.js"],"LessonTableOfContents"] 1a:T550,A coding agent that can shell out can install backdoors, exfiltrate keys, brick a developer laptop, and rack up a cloud bill in a single turn. The least costly defense is to not give it shell. The second least costly is a sandbox that says no to a precise list of patterns. Three classes of failure recur in agent traces. The first is dangerous executables. A model under pressure to fix a path issue will try `sudo`, `chmod -R 777`, `rm -rf`, `mkfs`, `dd`. None of these belong in an agent run. The denylist catches them by name and by alias. The second is argv tricks. A model that has been told no shell will pipe an attack through an interpreter: `python3 -c "import os; os.system('rm -rf /')"`, `bash -c '...'`, `node -e '...'`, `perl -e '...'`. The sandbox needs to know that any interpreter run with a `-c`-like flag is just a shell call with extra steps. The third is path escape. The model is told to read `./src/main.py` and instead reads `../../etc/passwd`. The sandbox jails every path argument by resolving it through `os.path.realpath` and asserting the prefix. The sandbox is not a security boundary in the operating system sense. A determined attacker with code execution can still break out. The sandbox is a development-time guardrail: it makes the common failure modes loud and stops the agent from doing damage out of sheer ineptitude.1b:T41a,```mermaid flowchart TD Call[ToolCall
already passed gate chain] --> Run["Sandbox.run()"] Run --> S1[1. resolve executable against denylist
rm, sudo, mkfs, ...] S1 --> S2[2. inspect argv
interpreter -c, shell metachars when shell=False] S2 --> S3[3. resolve path-like arguments
against project_root via realpath] S3 --> S4[4. spawn subprocess
capture, wall-clock timeout, env scrub] S4 --> S5[5. truncate stdout/stderr to max_output_bytes] S5 --> Result[SandboxResult
exit_code, stdout, stderr,
truncated, timed_out, denied, reason] ``` The sandbox has four refusal axes: name, argv, path, structure. Each axis is a pure function of the call, no subprocess yet. The subprocess only spawns after every axis has passed. The `SandboxResult` exit codes are the conventional ones: 0 success, non-zero failure, plus three sentinel codes for denied (-100), timed_out (-101), and truncated (the exit code is the real one, with a flag set). Downstream lessons read this structured result rather than parsing stderr.1c:T44b,```mermaid flowchart LR Harness[AgentHarness
lesson 20-25] -->|call| Sandbox[Sandbox
denylist
path jail
argv inspect
timeout
truncation] Sandbox -->|exec| Popen[subprocess.Popen] Sandbox --> Result[SandboxResult] ``` The denylist is a frozenset of executable basenames. Aliases (`/bin/rm`, `/usr/bin/rm`) all resolve to the same basename. The argv inspector knows the interpreter shape: any argv where argv[0] is an interpreter and any later arg starts with `-c` or `-e` is denied. Shell metacharacters (`;`, `|`, `&`, `>`, `<`, backticks, `$()`) cause refusal when the call did not explicitly request a shell. The path jail is the most subtle piece. The sandbox accepts a `project_root` at construction. Any argument that looks like a path (contains `/` or matches an existing file) is normalized through `os.path.realpath`, then checked against the realpath of the project root. If the re