Codex’s approval policy doesn’t hold across runtimes — VS Code ignores it, Windows inverts it, and CI auto-approves any mid-session escalation since v0.113.0

What you expect

You configure approval_policy in .codex/config.toml to enforce a consistent approval gate across all Codex runtimes. workspace-write sandbox mode confines file writes to the project directory. External policy engines running alongside Codex can observe and govern what the agent does inside generated scripts.

What actually happens

CVE-level trust boundary failures (patched, but diagnostic)

Before v0.23.0, a repo could commit a .env setting CODEX_HOME=./.codex, add a .codex/config.toml defining [mcp_servers] with shell commands, and Codex would execute those commands at session startup without an approval prompt. Anyone who cloned the repo triggered the execution. This is CVE-2025-61260 (CVSS 9.8), disclosed by Check Point Research and patched in v0.23.0.

In Codex 0.2.0–0.38.0, workspace-write was not a real containment boundary. The model-generated working directory also became the sandbox’s writable root, so a model that chose a cwd outside the project folder could write there. The fix (GHSA-w5fx-fh39-j5rw / CVE-2025-59532, CVSS 8.6) separated the conversation cwd from the sandbox-policy cwd in commit 8595237505a1e0faabc2af3db805b66ce3ae182d. The boundary only became real after the code change.

These CVEs are patched. They confirm a pattern: Codex trust boundaries are code-enforced runtime properties, not configuration guarantees.

Approval policy drifts by runtime (still active)

The same config.toml does not produce the same approval behavior on all Codex runtimes:

• VS Code extension <0.4.12 (issue #7963): The extension silently ignored approval_policy = "untrusted" and continued auto-editing files. Fixed in extension 0.4.12, but the episode demonstrates that approval_policy enforcement was not a stable cross-runtime guarantee.
• Standalone Windows Codex App (issue #24934, open): The opposite failure — a session whose rollout metadata already showed approval_policy = "never", sandbox_policy = "danger-full-access", and permission_profile = "disabled" still prompted for manual command approval (e.g. before running cargo test). The effective runtime context was already no-approval/full-access, but the approval UI fired anyway.
• Native Windows sandbox ACLs (issue #12343, closed): A separate Windows-specific issue — CodexSandboxOffline, CodexSandboxOnline, and CodexSandboxUsers groups were provisioned with access to C:\Users\ and subfolders, with stale SIDs remaining after uninstall.

Checked-in config is therefore not sufficient evidence for runtime behavior. Platform, version, and runtime surface each affect enforcement.

Auto-approved permission escalation in CI (v0.113.0+, still active)

v0.113.0 introduced request_permissions as a built-in tool that the model can invoke mid-execution to expand its own sandbox permissions. In automated (unattended) sessions — the environments most likely to run Codex for CI and agent-in-CI workflows — the default behavior is auto-approval: without an explicit reject_config, any request_permissions call is granted.

This creates a mid-execution permission expansion path that bypasses the human approval loop specifically in the scenarios where unsupervised Codex is most commonly deployed. An initial permission_profile that defines a tight permission envelope does not constrain a model that can request its own permissions at runtime.

Related: PR #19595 (v0.128.0) adds another escalation step — when sandbox_permissions=require_escalated is used, an approved out-of-sandbox exec bypasses the managed network proxy entirely. One escalation approval grants both exec permissions and unfiltered network access with no second user action.

Silent config breakage on version upgrade (v0.115.0, still active)

v0.115.0 renamed the approval_policy value "reject" to "granular". Configs using approval_policy = "reject" silently fell back to defaults on upgrade — no error, no warning, no migration path. Any automated tooling, deployment script, or team runbook referencing "reject" became silently misconfigured.

v0.117.0 (PR #15036) introduced a related failure: the command_might_be_dangerous safety check is disabled when the session is explicitly unsandboxed. Teams that set sandbox_mode = "danger-full-access" to solve the hidden-skills editing problem (editing .agents/skills is awkward under workspace-write) simultaneously disable the danger-check gate as a side effect.

The governance middleware blind spot (structural)

Codex’s standard operation mode — model generates code, shell tool executes it — presents as a single tool-call step to external governance layers. Cedar/OPA policy engines, AGT middleware, and path-based governance frameworks see one shell or execute_code call. Everything inside the generated script — file reads, network requests, credential access, exfiltration commands — is invisible to the governance engine.

arxiv:2603.16586 (“Runtime Governance for AI Agents: Policies on Paths”) names this the generated-code completeness gap and flags it specifically for coding agents. The governance boundary is the tool call, not the script content. Runtime isolation (container boundaries, network egress controls, filesystem ACLs) is the only enforcement layer that applies to generated code execution — policy engines cannot substitute for it.

What this means for you

Teams that use approval_policy in checked-in Codex config as their primary safety gate have a false sense of determinism. Three failure modes exist in parallel:

1. Runtime variance: the same config produces different enforcement on CLI vs VS Code vs Windows. You cannot verify approval behavior from config alone without specifying the exact runtime and version.

2. Auto-escalation in CI: any automated Codex workflow running v0.113.0+ without reject_config will auto-approve any request_permissions call the model makes mid-session. CI and agent-in-CI patterns are the highest-risk environments and the ones where this default matters most.

3. Governance middleware gap: if your security model depends on a policy engine observing Codex tool calls, that engine cannot see what Codex does inside generated scripts. This is architectural, not a Codex bug.

What to do

1. Verify you are on v0.23.0+ and have updated the VS Code extension to 0.4.12+. The two patched CVEs are the minimum baseline.

2. Add reject_config to all automated Codex sessions. Without it, request_permissions calls are auto-approved. This applies to CI workflows, agent-in-CI, and any unattended session where a human is not in the approval loop.

3. Audit permission_profile, not just sandbox_mode. From v0.113.0+, sandbox_mode is a coarse toggle; permission_profile provides per-path and per-host control. Repos that only set sandbox_mode are not getting fine-grained control. Treat the presence of permission_profile as a meaningful security signal in repo scanning.

4. Check for approval_policy = "reject" in existing configs. This value was renamed to "granular" in v0.115.0. Any config still using "reject" silently falls back to defaults.

5. Do not treat sandbox_permissions=require_escalated as a network control. Since v0.128.0, an approved escalated exec bypasses the managed network proxy. Treat any approved out-of-sandbox exec as also granting unfiltered network access.

6. Distinguish @openai/codex npm package from the Rust binary in CVE scanning. CVE-2025-61260 and npm-sourced CVE analyses apply to the JavaScript package only. Repos using the Rust binary require separate scanner logic — npm-based CVE detection produces false negatives for them.

7. Use container boundaries and filesystem ACLs, not policy engines, to constrain generated code. External governance middleware (Cedar/OPA, AGT, path-based frameworks) cannot inspect generated scripts. Only runtime isolation enforces what generated code can do.

Falsification criterion: This finding would be disproved by documentation or release notes confirming that approval_policy enforcement is now verified identical across CLI, VS Code extension, and Windows on the same config.toml, and that request_permissions requires explicit user confirmation in automated sessions by default — along with an independent confirmation (issue closure, advisory update, or third-party audit) that the auto-escalation behavior in CI no longer applies.

Evidence

Tool	Version	Evidence	Result
OpenAI Codex CLI	<0.23.0	independently-confirmed	CVE-2025-61260 (CVSS 9.8): repo-local .codex/config.toml MCP commands executed at session start without approval; confirmed by Check Point Research, SecurityWeek, and CSO Online
OpenAI Codex CLI	0.2.0–0.38.0	independently-confirmed	GHSA-w5fx-fh39-j5rw (CVE-2025-59532, CVSS 8.6): model-chosen cwd became sandbox writable root, bypassing workspace-write; confirmed in Wiz, GitLab Advisory Database, Miggo vulnerability database
OpenAI Codex CLI	v0.113.0+	source-reviewed	request_permissions auto-approved in unattended sessions without reject_config; documented in v0.113.0 release notes
OpenAI Codex CLI	v0.115.0	source-reviewed	approval_policy = "reject" renamed to "granular" silently; old configs fall back to defaults with no error or warning
OpenAI Codex CLI	v0.128.0	source-reviewed	sandbox_permissions=require_escalated exec bypasses managed network proxy (PR #19595); one escalation approval grants both exec and unfiltered network
OpenAI Codex CLI	v0.117.0+	source-reviewed	command_might_be_dangerous check disabled when explicitly unsandboxed (PR #15036); danger gate and approval gate bypass together
Codex VS Code Extension	<0.4.12	source-reviewed	approval_policy = "untrusted" silently ignored; extension auto-edited files (issue #7963, now closed/fixed)
Codex Windows App	0.131.0-0.133.0	source-reviewed	approval_policy=never + sandbox_policy=danger-full-access + permission_profile=disabled still triggers manual command-approval prompts (issue #24934, open)
Codex CLI (Windows)	native Windows	source-reviewed	CodexSandboxOffline/Online/Users groups had C:\Users\ access; stale SIDs after uninstall (issue #12343, closed)
Codex CLI	all versions	source-reviewed	Generated-code completeness gap: Cedar/OPA/AGT see one shell tool call regardless of script complexity (arxiv:2603.16586)

Confidence: empirical — 9 environments reviewed across 5 version ranges. Independently confirmed by Check Point Research, GHSA-w5fx-fh39-j5rw, and depth-verified 2026-03-30 (6/7 primary claims confirmed via HTTP 200 on primary sources).

Strongest case against: All three of the worst behaviors documented here are patched or resolved: CVE-2025-61260 is fixed in v0.23.0 (late 2025), GHSA-w5fx-fh39-j5rw is fixed in v0.39.0, and the VS Code extension approval-policy drift is fixed in 0.4.12. Teams running current versions of Codex CLI with properly configured reject_config and permission_profile have substantially better isolation than the CVE-era surface. The request_permissions auto-approval concern requires a threat model where the model itself attempts escalation mid-session, which is a different risk class from the repository-supplied malicious config that the CVEs addressed. The governance middleware gap is structural to all code-execution agents, not a Codex-specific defect. Staleness risk is high: the unreviewed version range v0.129.0–v0.141.0 may contain further security-relevant changes not reflected here.

Open questions: Does reject_config fully neutralize the request_permissions auto-approval behavior on current versions, or are there edge cases? What are the security-relevant changes in Codex CLI v0.129.0–v0.141.0 (unreviewed as of 2026-06-20)? Does the Windows sandbox SID issue persist on current native Windows builds?

Seen different? Contribute your evidence — share a repro or counter-example and we’ll review it against this finding. Reader evidence is what keeps these findings accurate.