execute autonomy on an unfamiliar repo, and whenever a task pulls untrusted input.A permission mode decides whether a call runs. A sandbox decides what a command can reach once it\nis running, and the OS enforces that on every child process. An unattended loop needs the second\nkind: nobody is at the prompt to answer for the first.
\nThe configuration and container example below are Claude Code-specific. Do not copy those\nsettings into Codex. For Codex, use its native sandbox and approval controls as documented in\nthe configuration reference.\nA read-only sandbox constrains filesystem writes; approval policy is a separate control.\nNative hooks are not a replacement for OS confinement. Custom Codex role defaults can be\nsuperseded by the parent turn's permissions; see docs/runtime-controls.md before delegating\nwork that requires a hard boundary. Client qualification remains in the compatibility catalog.
It \"runs on macOS, Linux, and WSL2. Native Windows is not supported\"; Linux and WSL2 need\nbubblewrap and socat installed first. Put this in ~/.claude/settings.json to cover every\nproject; the /sandbox panel writes enabled to .claude/settings.local.json for one project.
{\n \"sandbox\": {\n \"enabled\": true,\n \"failIfUnavailable\": true,\n \"allowUnsandboxedCommands\": false,\n \"network\": { \"allowedDomains\": [], \"strictAllowlist\": true },\n \"filesystem\": { \"denyRead\": [\"~/.ssh\", \"~/.aws\", \"~/.config/gh\"] }\n }\n}\nstrictAllowlist over an empty allowedDomains is network off: Claude Code then \"denies sandboxed\ncommands access to any host outside the allowlist instead of prompting\". Only user, managed and\n--settings settings set it; a repository's own file cannot. The deny entries are load-bearing —\nthe default read policy covers the whole disk, and \"this default still allows reading credential\nfiles such as ~/.aws/credentials and ~/.ssh/.\" Add sandbox.credentials.envVars entries with\n\"mode\": \"deny\" to unset tokens for sandboxed commands too. failIfUnavailable makes a missing\ndependency a hard stop rather than a silent unsandboxed fallback, and allowUnsandboxedCommands: false removes the retry-outside escape hatch. Subagents inherit the session's sandbox; commands\nyou type at the ! prompt do not.
For one session, writing no file: claude --settings '{\"sandbox\":{\"enabled\":true}}'. Confirm with\n/sandbox: the Config tab shows the resolved settings, and a Dependencies tab appearing\nmeans a package is missing. A prompt titled \"Bash command (unsandboxed)\" is the signal a command\nleft the boundary. Keys and defaults: https://code.claude.com/docs/en/sandboxing
Harder boundary, coarser tooling. Mount the worktree and nothing else, stay non-root, and let the\ncontainer be the isolation — do not nest the built-in sandbox inside it.
\ndocker run --rm -it --network none \\\n --user \"$(id -u):$(id -g)\" \\\n -v \"$PWD:/work\" -w /work \\\n -v \"$HOME/.claude:/config:ro\" -e CLAUDE_CONFIG_DIR=/config -e ANTHROPIC_API_KEY \\\n <image-with-the-cli> claude --dangerously-skip-permissions -p \"<the loop prompt>\"\npodman substitutes unchanged. What breaks, in order: --network none cuts the model API too, so\nas written this runs only against a local model — for a loop that must reach the API, allow that\none host and nothing else and the shape holds. Then web search and fetch, every MCP server reached\nover the network, and every package install; a read-only config mount blocks session state and\ncredential writes, so auth arrives by environment variable. Losing all of it is the point when the\ntask parses input you did not write: a path the loop lacks cannot be talked into opening.
Built-in sandbox for daily work: a settings change, every tool still works, the OS still enforces\nthe boundary. Container for a loop that runs while you sleep, a repo whose build scripts you have\nnot read, or anything handling untrusted content. Neither isolates branches — run inside a\nworktree as well, per the worktree-per-agent skill.