Codex sandbox and approvals: modes, network access and presets

The Codex sandbox is the OS-enforced boundary that limits what commands run by Codex can touch. By default, Codex can read files, edit inside your workspace and run routine commands there, with network access off. An approval policy decides when Codex must stop and ask before crossing that boundary. Together they set how much Codex does on its own.

This guide covers the three sandbox modes, approval policies, network access, protected paths, OS enforcement and presets, from OpenAI's Sandbox and Agent approvals & security pages, read on 24 October 2026. For where these settings live, see the Codex config.toml guide.

What does the Codex sandbox do?

It applies to every command Codex spawns, not just its own file edits. If Codex runs git, a package manager or your test runner, those programs inherit the same limits. It works the same way in the Codex CLI, the IDE extension and local chats in the desktop app.

OpenAI's docs separate the two controls clearly: "The sandbox defines technical boundaries. The approval policy decides when the agent must stop and ask before crossing them." The payoff is fewer prompts. Codex can do low-risk work without asking, and you only hear from it when a task needs more access.

What are the three sandbox modes?

Choose one per run with --sandbox (or -s), or set a default:

# ~/.codex/config.toml
sandbox_mode = "workspace-write"

The workspace includes the current folder plus temporary directories such as /tmp. Run /status to see exactly which directories are included. When Codex needs another folder, --add-dir path grants write access to it without dropping the sandbox, and sandbox_workspace_write.writable_roots does the same in config.

Which approval policies can you use?

The approval policy controls when Codex pauses:

• on-request: Codex works inside the sandbox and asks when it needs to go beyond it, such as editing outside the workspace or using the network.
• never: Codex never stops for approval. It still respects the sandbox and does its best within those limits.
• Granular: approval_policy = { granular = { ... } } keeps some prompt categories interactive and rejects others automatically. It covers sandbox approvals, rules prompts, MCP prompts, request_permissions prompts and skill-script approvals.

Set it with --ask-for-approval (-a) or approval_policy in config.

The untrusted policy is retired. OpenAI's docs warn that approval_policy = "untrusted" "can prevent either client from starting." Remove it from user config, project config, profiles and scripts. For the old strict behavior, leave approval_policy unset and add a project entry to ~/.codex/config.toml instead:

[projects."/path/to/project"]
trust_level = "untrusted"

Commands in that project then need approval unless a rule allows them, and project-local config is disabled. Explicitly setting on-request overrides the project-derived policy.

Who reviews approvals?

approvals_reviewer decides who answers a prompt. The default is user. Set auto_review and eligible requests go to a separate reviewer agent first, with the same sandbox boundary. The reviewer checks for data exfiltration, credential probing, persistent security weakening and destructive actions, and it fails closed on errors. It uses extra model calls, so it adds to usage. The Auto-review page has the details.

What are the Codex presets?

These combinations follow OpenAI's table of common setups, with the CLI's --approve-for-me shortcut added:

In the IDE extension and desktop app, the permissions control under the composer shows these as Ask for approval, Approve for me and Full access. In the CLI, type /permissions to switch. When you launch Codex in a folder under version control, it recommends Auto; outside version control it recommends read-only.

You can save a preset as a profile file and load it with codex --profile name:

# ~/.codex/readonly_quiet.config.toml
approval_policy = "never"
sandbox_mode    = "read-only"

How does network access work?

Network access is off by default. To let commands reach the internet in workspace-write mode:

[sandbox_workspace_write]
network_access = true

That gives unrestricted outbound access. To limit it to specific destinations, also turn on the network_proxy feature with domain rules:

[features.network_proxy]
enabled = true
domains = { "api.openai.com" = "allow", "example.com" = "deny" }

The proxy never grants network access by itself; with network off it does nothing. Domain rules are allowlist-first: *.example.com matches subdomains only, **.example.com matches the apex and subdomains, and deny always wins. Local and private addresses stay blocked unless you add an exact localhost or IP rule.

The proxy does not filter web search, MCP server connections, app tool calls or cloud tasks, which have their own controls. Web search defaults to cached mode, which returns results from an OpenAI-maintained index instead of fetching live pages. Use --search or web_search = "live" for live results, or "disabled" to turn it off.

Which paths stay protected?

Even in workspace-write, some folders inside each writable root are read-only:

• .git, whether it is a folder or a pointer file (and the real Git directory a pointer file points to)
• .agents, when it exists as a folder
• .codex, when it exists as a folder
• .aws, when it exists as a folder

Protection is recursive, so sandboxed commands cannot write to your Git directory, Codex config, skills folder or AWS credentials.

How is the sandbox enforced on each OS?

• macOS: Seatbelt policies through sandbox-exec. Works out of the box.
• Linux and WSL2: bwrap plus seccomp. Install bubblewrap first (sudo apt install bubblewrap or sudo dnf install bubblewrap). WSL1 is no longer supported.
• Windows: Codex's native Windows sandbox in PowerShell, or the Linux sandbox inside WSL2.

In Docker, the inner sandbox may fail if the container blocks namespaces or seccomp. OpenAI's advice is to make the container the boundary and run Codex with --sandbox danger-full-access inside it, with the warning that a malicious project could then reach anything in the container, including Codex credentials. Use that pattern only with trusted repositories.

To see what a command does under the sandbox, test it directly:

codex sandbox macos --log-denials npm test
codex sandbox linux npm test

How do rules give narrow exceptions?

When one command keeps needing approval, a rule beats widening the sandbox. Rules live in .rules files under a rules/ folder next to a config layer, such as ~/.codex/rules/default.rules, and are marked experimental. This example is adapted from OpenAI's rules page, trimmed to leave out its optional match and not_match test lists:

prefix_rule(
    pattern = ["gh", "pr", "view"],
    decision = "prompt",
    justification = "Viewing PRs is allowed with approval",
)

decision can be allow, prompt or forbidden, and the most restrictive match wins. Project rules in .codex/rules/ load only for trusted projects.

Tips for a safe Codex setup

• Stay on Auto in a Git repo. A clean working tree makes every change easy to review and revert.
• Grant folders, not full access. --add-dir keeps the sandbox on for everything else.
• Pick the narrowest approval scope. Approve once rather than for the session when you can.
• Turn on the network proxy before opening the network so commands reach only the hosts you list.
• Treat web content as untrusted. Prompt injection is the main risk once network or live search is on.

Keep your skills safe from the sandbox and from loss

The sandbox protects .agents precisely because skills shape what Codex does. Keep those folders under version control too: Kipt stores prompts and Agent Skills as Markdown in a private GitHub repo you own and installs them into Codex with one npx skills add command. The Codex skills guide covers where Codex reads them from.