sandbox_workspace_write.network_access
falsePublished Jul 15, 2026 · Verified against the official config docs
Boolean under [sandbox_workspace_write] that gives sandboxed commands outbound network access. Default is false, so even in workspace-write mode, npm install, pip install, and curl fail until you set it true in ~/.codex/config.toml. This is the narrow fix for most sandbox network failures and beats turning the sandbox off entirely, since filesystem limits stay in place.
network_access lives under the [sandbox_workspace_write] table in ~/.codex/config.toml. It only does anything when sandbox_mode = "workspace-write"; read-only mode blocks writes anyway, and danger-full-access skips the sandbox entirely.
Values
| Value | What happens |
|---|---|
false (default) |
Sandboxed commands get no outbound network. npm install, pip install, curl all fail. |
true |
Sandboxed commands can reach the network. Filesystem limits still apply. |
sandbox_mode = "workspace-write"
[sandbox_workspace_write]
network_access = true
Sibling keys in the same table: exclude_slash_tmp and exclude_tmpdir_env_var (both boolean, both default false) pull /tmp and $TMPDIR out of the writable set, and writable_roots adds extra writable paths. All four are on the official reference.
When to change it
- Package installs fail inside a Codex session while the exact same command works in your own terminal. That is the classic tell the sandbox is blocking outbound traffic.
- Test suites or scripts that hit an API fail with connection errors. Same fix.
- Try it as a one-off before committing:
codex -c sandbox_workspace_write.network_access=trueuses the documented-coverride and only affects that session.
If you were about to set sandbox_mode = "danger-full-access" just to get npm install working, set this key instead. You keep the filesystem fence and lose nothing you needed.
Gotchas
- The Codex desktop app has ignored this key while the CLI honored it (#13373). If the app still blocks network after you set
true, you hit a known bug, and the workaround discussion is in that thread. - On Windows, users report DNS resolution failing in the sandbox even with network enabled (#18675).
trueis all-or-nothing, with no domain allowlist on this key. For filtered outbound traffic, Vaughan’s proxy writeup covers the permission-profile route with per-domain allow and deny rules (deny wins on conflict).- The reference doesn’t say whether flipping this changes approval prompting. From the docs alone, it opens the network and nothing else.
Related settings
sandbox_modepicks which sandbox this table applies to.approval_policycontrols when Codex asks before running commands at all.- Landed here from the “retry without sandbox” error? The fix page is at /errors/sandbox-error-retry-without-sandbox/.