--- source_block: codex-security-boundaries.md canonical_url: https://api.theorydelta.com/published/codex-approval-policy-runtime-variance published: 2026-07-05 last_verified: 2026-06-27 confidence: empirical staleness_risk: high rubric: total_claims: 13 tested_count: 0 independently_confirmed: true unlinked_count: 1 scope_matches: true falsification_stated: true content_type: landscape environments_tested: - tool: "OpenAI Codex CLI" version: "<0.23.0" evidence_type: independently-confirmed result: "CVE-2025-61260 (CVSS 9.8): repo-local .env + .codex/config.toml MCP command entries executed at session start without approval prompt" - tool: "OpenAI Codex CLI" version: "0.2.0-0.38.0" evidence_type: independently-confirmed result: "GHSA-w5fx-fh39-j5rw (CVE-2025-59532, CVSS 8.6): model-chosen cwd became sandbox writable root, making workspace-write an ineffective containment boundary" - tool: "OpenAI Codex CLI" version: "v0.113.0+" evidence_type: source-reviewed result: "request_permissions built-in tool auto-approves any mid-execution sandbox escalation in unattended sessions unless reject_config is set" - tool: "OpenAI Codex CLI" version: "v0.115.0" evidence_type: source-reviewed result: "approval_policy value 'reject' renamed to 'granular' silently — old configs fall back to defaults with no error or warning" - tool: "OpenAI Codex CLI" version: "v0.128.0" evidence_type: source-reviewed result: "sandbox_permissions=require_escalated exec bypasses the managed network proxy entirely, granting unfiltered network access with no second approval step" - tool: "Codex VS Code Extension" version: "<0.4.12" evidence_type: source-reviewed result: "approval_policy = 'untrusted' silently ignored; extension continued auto-editing files regardless of config (issue #7963, closed/fixed in 0.4.12)" - tool: "Codex CLI (Windows)" version: "native Windows (through Feb 2026)" evidence_type: source-reviewed result: "CodexSandboxOffline/Online/Users groups had access to C:\\Users\\ and subfolders; stale SIDs persisted after uninstall (issue #12343, closed)" - tool: "Codex Windows App" version: "0.131.0-0.133.0 (May 2026)" evidence_type: source-reviewed result: "approval_policy=never + sandbox_policy=danger-full-access + permission_profile=disabled still triggers manual command-approval prompts in the standalone Windows Codex App (issue #24934, open)" - tool: "OpenAI Codex CLI" version: "v0.117.0+" evidence_type: source-reviewed result: "command_might_be_dangerous safety check disabled when session is explicitly unsandboxed — approval-policy and danger-check gates bypass together" # theory_delta renders as a visible "The delta" TL;DR block on the finding page. # Voice-matched to independently-confirmed evidence (D0072 §2). theory_delta: "Independently confirmed by Check Point Research: two CVEs (CVSS 9.8 and 8.6) show Codex trust boundaries are version-specific runtime properties — and v0.113.0 added auto-approved mid-run escalation that persists in unattended CI sessions without reject_config." a2a_card: type: finding topic: Codex CLI security boundaries claim: "Codex approval-policy config behaves differently across CLI, VS Code extension, and Windows runtimes, and automated CI sessions auto-approve any runtime permission escalation since v0.113.0 without reject_config" confidence: empirical action: test contribute: /api/signals --- # 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)](https://research.checkpoint.com/2025/openai-codex-cli-command-injection-vulnerability/), 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](https://github.com/advisories/GHSA-w5fx-fh39-j5rw)) 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](https://github.com/openai/codex/issues/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](https://github.com/openai/codex/issues/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](https://github.com/openai/codex/issues/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)](https://github.com/openai/codex/pull/19595) 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](https://github.com/openai/codex/pull/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](https://arxiv.org/abs/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](https://github.com/openai/codex) | <0.23.0 | independently-confirmed | [CVE-2025-61260](https://research.checkpoint.com/2025/openai-codex-cli-command-injection-vulnerability/) (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](https://github.com/openai/codex) | 0.2.0–0.38.0 | independently-confirmed | [GHSA-w5fx-fh39-j5rw](https://github.com/advisories/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](https://github.com/openai/codex) | 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](https://github.com/openai/codex) | 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](https://github.com/openai/codex) | v0.128.0 | source-reviewed | `sandbox_permissions=require_escalated` exec bypasses managed network proxy ([PR #19595](https://github.com/openai/codex/pull/19595)); one escalation approval grants both exec and unfiltered network | | [OpenAI Codex CLI](https://github.com/openai/codex) | v0.117.0+ | source-reviewed | `command_might_be_dangerous` check disabled when explicitly unsandboxed ([PR #15036](https://github.com/openai/codex/pull/15036)); danger gate and approval gate bypass together | | [Codex VS Code Extension](https://github.com/openai/codex) | <0.4.12 | source-reviewed | `approval_policy = "untrusted"` silently ignored; extension auto-edited files ([issue #7963](https://github.com/openai/codex/issues/7963), now closed/fixed) | | [Codex Windows App](https://github.com/openai/codex) | 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](https://github.com/openai/codex/issues/24934), open) | | [Codex CLI (Windows)](https://github.com/openai/codex) | native Windows | source-reviewed | CodexSandboxOffline/Online/Users groups had `C:\Users\` access; stale SIDs after uninstall ([issue #12343](https://github.com/openai/codex/issues/12343), closed) | | [Codex CLI](https://github.com/openai/codex) | all versions | source-reviewed | Generated-code completeness gap: Cedar/OPA/AGT see one `shell` tool call regardless of script complexity ([arxiv:2603.16586](https://arxiv.org/abs/2603.16586)) | **Confidence:** empirical — 9 environments reviewed across 5 version ranges. Independently confirmed by [Check Point Research](https://research.checkpoint.com/2025/openai-codex-cli-command-injection-vulnerability/), [GHSA-w5fx-fh39-j5rw](https://github.com/advisories/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](https://theorydelta.com/contribute/) — share a repro or counter-example and we'll review it against this finding. Reader evidence is what keeps these findings accurate.