In the official definition, sandbox mode governs exactly one thing: file system effects. Network and process visibility are outside this vocabulary — do not assume tightening the sandbox also limits network access.
| Mode | Permits | Typical use |
|---|---|---|
| read-only | Only required sinks such as /dev/null. Not even the workspace is writable | Read-only analysis, code review, research |
| workspace-write | Writes under the workspace root plus a backend-provided temp area | Most daily work: editing files, producing artifacts |
| danger-full-access | Bypasses confinement and spawns the raw process | When you know exactly why you need to leave the workspace |
The docs are explicit: only the first two modes are sent to a provider. The danger-full-access consumer spawns raw argv and never calls ctx.sandbox. It is not a wider sandbox; it is no sandbox.
One recipe under two permissions
Run a recipe that writes a file (say, generate an index .md) under both modes and watch:
- read-only: no artifact. It may error, or it may report success while the file does not exist — the second is worse.
- workspace-write: the artifact appears inside the workspace; paths outside still fail.
- danger-full-access: writes outside the workspace succeed too. Now nothing in the mechanism answers 'did it overstep'; only your own reading does.
One easily missed fact: enforcement can be partial
The docs define SandboxEnforcement as full or partial. Partial means the active backend or an older kernel ABI governs only a subset of the promised effects — known cases include older Landlock ABIs and the Everyone and hardlink boundaries on the Windows ACL backend.
Practical takeaway: if you need a hard 'cannot write outside the workspace' guarantee, confirm the backend reports full. Under partial it is not a hard boundary. That matters more than the mode name.