Codex security: sandbox, approvals and what a team should set

Codex security comes down to two layers you configure: the sandbox, which sets what commands can technically do, and the approval policy, which decides when Codex must ask before crossing that line. Locally, the defaults are sensible: network off, writes limited to the workspace. A team should then lock the settings that matter, keep secrets out of the environment, and treat AGENTS.md as guidance, not enforcement.

Does "Codex security" mean the scanner or the agent?

Both, and they are different things. OpenAI's Codex Security is a product for scanning connected GitHub repositories for vulnerabilities and reviewing fixes. This guide is about the other meaning: securing the Codex coding agent in its CLI, IDE extension and desktop app, and its cloud tasks. If you want the scanner, OpenAI's documentation has a separate Codex Security section.

How does the Codex sandbox work?

When Codex runs commands locally, it runs them inside a constrained environment. The sandbox applies to spawned commands, so git, package managers and test runners inherit the same limits. Enforcement is done by the operating system: Seatbelt on macOS, bubblewrap on Linux and WSL2, and a native sandbox on Windows. On Linux you should install bubblewrap yourself, because without it Codex falls back to a bundled helper that needs unprivileged user namespaces.

There are three legacy sandbox_mode values:

• read-only: commands can read but not change files
• workspace-write: commands can write in the workspace and temporary directories
• danger-full-access: no filesystem sandbox

By default, network access is off and writes are limited to the active workspace. Even inside a writable workspace, some paths stay read-only: .git, and .agents, .codex and .aws when they exist as directories. That last one protects AWS credentials from being overwritten by a command, though it does not say they cannot be read.

Newer builds (0.138.0 and later) add permission profiles, which are marked beta. The built-in profiles are :read-only, :workspace and :danger-full-access, and you can define your own with filesystem and network rules. A profile cannot be combined with sandbox_mode; use one or the other.

What are Codex approval policies?

An approval policy controls when Codex pauses for your consent. The supported values for approval_policy are:

• on-request: Codex works inside the sandbox and asks when it wants to leave it, such as editing outside the workspace or running a command that needs network access
• never: Codex does not ask, and acts within the sandbox it has
• a granular table that keeps some prompt categories interactive and rejects others

The older untrusted value is retired as an explicit setting, and a leftover approval_policy = "untrusted" can stop the client from starting. on-failure is deprecated.

Combinations people actually use:

Intent	Flags	Effect
Default "Auto" preset	--sandbox workspace-write --ask-for-approval on-request	Reads, edits and commands in the workspace run freely; edits outside it and network access need approval
Safe browsing	--sandbox read-only --ask-for-approval on-request	Reads and read-only commands; anything outside asks
Read-only CI	--sandbox read-only --ask-for-approval never	Never asks, never writes
No guardrails	--dangerously-bypass-approvals-and-sandbox (alias --yolo)	No sandbox, no approvals

The last row is the one to block. Codex can also route eligible approval requests to a reviewer agent with approvals_reviewer = "auto_review". That reviewer only sees actions that already needed approval, and OpenAI's description says it checks for data exfiltration, credential probing, persistent security weakening and destructive actions.

How should you handle Codex network access?

Keep it off unless a task needs it. To allow it in the workspace-write sandbox:

[sandbox_workspace_write]
network_access = true

Turning access on opens everything, so pair it with the network_proxy feature, which limits command traffic to destinations you list. Adding domain rules does not enable the proxy by itself. The domain policy is allowlist-first, deny always beats allow, and a global * allow rule means any public host not denied, so prefer scoped rules.

Know what the proxy does not filter. According to the documentation it covers scripts, programs and child processes inside the command sandbox. It does not filter web search, app and connector calls, MCP server connections, browser or Computer Use activity, cloud tasks, or the client's own model requests. Each of those has its own control.

Web search defaults to a cached, OpenAI-maintained index rather than live pages, which OpenAI says reduces exposure to prompt injection from arbitrary live content. Under --yolo or another full-access setting it defaults to live results. Treat results as untrusted either way. See our guide to prompt injection in coding agents for why.

Where does Codex read its configuration?

User settings live in ~/.codex/config.toml. Projects can add .codex/config.toml, and Codex loads project .codex/ layers only when you trust the project. Precedence, highest first, runs: CLI flags and --config overrides, project config files, profile files, user config, cloud-managed defaults, /etc/codex/config.toml, then built-in defaults. If you mark a project as untrusted, Codex skips its project-local config, hooks and rules.

A conservative personal baseline is short:

approval_policy = "on-request"
sandbox_mode    = "workspace-write"

Does AGENTS.md enforce security rules?

No. Codex reads AGENTS.md before doing work and builds an instruction chain from ~/.codex/AGENTS.md (or AGENTS.override.md) and files from the project root down to the working directory, up to a 32 KiB combined default. That is guidance for the model. A line saying "never read .env" is a request the model may or may not honor, and an attacker who can edit the file can change it.

Treat these files like CI configuration: put them under code review, and use them for conventions, test commands and team norms. Enforce anything security-relevant elsewhere.

How do rules control commands outside the sandbox?

Rules, currently marked experimental, decide what happens when Codex wants to run a command outside the sandbox. They live in .rules files under a rules/ folder next to an active config layer, such as ~/.codex/rules/default.rules, and use a Starlark syntax:

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

A decision is allow (run outside the sandbox without prompting), prompt, or forbidden, and the most restrictive match wins. Codex splits simple compound commands like git add . && rm -rf / and checks each part. For scripts with redirection, substitutions or variables, it evaluates the whole bash -lc string as one command. Test a rule with codex execpolicy check --pretty --rules <file> -- <command>.

How do you keep secrets away from Codex?

Start with the environment. shell_environment_policy controls which variables reach spawned commands, and the default may surprise you: ignore_default_excludes is true, so Codex does not automatically strip variables whose names contain KEY, SECRET or TOKEN. To change that and trim the rest:

[shell_environment_policy]
inherit = "core"
ignore_default_excludes = false

[shell_environment_policy.filters]
"AWS_*" = "exclude"
"AZURE_*" = "exclude"

Next, block files. In a permission profile, a deny entry blocks reads and writes under a path, for example "**/*.env" = "deny" under :workspace_roots. On Linux, WSL and native Windows, glob matches are enumerated when each sandboxed process starts, so a .env created later is still readable by a process that was already running. Administrators can enforce the same thing through managed requirements:

[permissions.filesystem]
deny_read = [
  "/**/*.env",
  "~/.ssh",
]

When deny-read requirements are present, the local runtime rejects full-access permissions. On native Windows, managed deny_read applies to direct file tools, and shell subprocess reads do not use that rule. The wider picture for every tool is in keeping secrets out of AI coding agents.

What can administrators lock down?

Managed requirements constrain approval policy, approvals reviewer, sandbox mode, permission profiles, web search mode, managed hooks, which MCP servers users can enable and which plugin marketplaces they can use. If a user's value conflicts with a requirement, the client falls back to a compatible value and notifies the user.

On Unix the system file is /etc/codex/requirements.toml, and on Windows it is %ProgramData%\OpenAI\Codex\requirements.toml. macOS MDM and workspace-delivered cloud requirements sit above it in priority. This example, taken from OpenAI's documentation, blocks --ask-for-approval never and --sandbox danger-full-access, including --yolo:

allowed_approval_policies = ["untrusted", "on-request"]
allowed_sandbox_modes = ["read-only", "workspace-write"]

The untrusted entry looks wrong next to the retirement note above, and it is easy to delete by mistake. OpenAI's documentation says the managed list has to include it for an explicit on-request setting to be permitted, so leave it in.

For Codex 0.138.0 or later, OpenAI prefers allowed_permission_profiles over allowed_sandbox_modes. Setting allowed_web_search_modes = ["cached"] prevents live web search even in full-access sessions. An mcp_servers allowlist in requirements enables only servers whose name and identity both match, and disables the rest, which is the same approval idea we describe in the MCP security guide.

Keep the CLI updated. CVE-2025-59532 let Codex CLI treat a model-generated working directory as the sandbox's writable root. It was fixed in CLI 0.39.0 and IDE extension 0.4.12.

Where Rechazo fits with Codex

Codex's sandbox governs commands it spawns, and its network proxy does not cover model requests, so what goes into a prompt is outside it. Rechazo, which is in waitlist stage, covers Codex among other agents, checking prompts for credentials before they leave the company.

What to set this week

1. Deploy a requirements.toml that allows only the untrusted and on-request approval policies and the read-only and workspace-write sandboxes, so never and --yolo stop working.
2. Add a deny_read requirement for .env files and ~/.ssh.
3. Set shell_environment_policy with ignore_default_excludes = false and filters for your cloud credentials.
4. Leave command network access off by default, and where it is needed turn on network_proxy with scoped domains.
5. Restrict web search to cached and set an mcp_servers allowlist.
6. Move any approval_policy = "untrusted" line out of configs and scripts.
7. Put AGENTS.md and .codex/ in your code-review rules.
8. Update the CLI and IDE extension on every machine.