Researchers Break OpenAI Codex Sandbox to Execute Unsandboxed Host Commands

Overview

Security researchers have detailed two critical sandbox escapes in OpenAI Codex—the AI vendor’s developer agent available via desktop application and command-line interface—that allowed attackers to achieve arbitrary host command execution on a developer’s machine. Discovered and reported by Oren Yomtov of Accomplish AI on August 12, the OpenAI Codex vulnerabilities allowed malicious code embedded inside an untrusted repository to escape Codex’s strictest isolation modes without triggering approval prompts or screen alerts.

The more severe flaw, dubbed “Heapjack,” allowed command execution directly out of Codex’s read-only mode simply by getting a developer to open a cloned repository and ask the agent a question about the code. The second flaw, named “Overpatch,” bypassed workspace write restrictions in the open-source Codex CLI tool by exploiting path validation logic during file patching.

OpenAI addressed both vulnerabilities within eight days of initial notification. However, the findings highlight a persistent design challenge across AI coding agents: placing security enforcement boundaries inside the execution environment they are meant to contain.

How the Heapjack Sandbox Escape Works

The Heapjack technique targets a background helper called node_repl, which OpenAI Codex Desktop automatically registers inside the global ~/.codex/config.toml configuration file during installation. Because this configuration is shared, standard command-line users inherit the tool automatically without explicit consent or notification.

To manage execution, node_repl spins up a single Node.js process containing two distinct JavaScript execution contexts: a trusted context holding proprietary OpenAI operational logic, and an untrusted context executing code generated by or originating from the AI agent. To authenticate commands sent from the trusted layer to an unsandboxed native parent process, OpenAI relied on a randomly generated UUID token generated fresh on every execution run.

However, while V8 contexts isolate global variables and execution scope, they do not isolate process memory. Both execution contexts share the exact same V8 heap.

An attacker operating within the untrusted JavaScript context can call v8.getHeapSnapshot() to capture an in-memory snapshot of the shared process heap. The untrusted script then iterates through memory strings matching standard UUID formats and sends them across the inter-process communication (IPC) pipe to the validation logic. If a token is incorrect, the service returns an “unauthorized” response; if the token is correct but accompanied by malformed arguments, it returns a distinct validation error. This differential error response acts as an oracle, allowing the untrusted context to quickly identify the real authentication token.

Once the attacker holds the valid token, they can write arbitrary IPC requests directly to the native parent process. Because the parent process trusts any request bearing a valid token, it executes those requests outside the sandbox at full user privileges. In proof-of-concept testing, researchers leveraged this access to launch native system binaries using the open command, interact directly with local Unix sockets (such as the Docker daemon socket), and rewrite global configuration files—all while Codex was operating in its most restricted, read-only mode.

Exploiting the Overpatch Logic Flaw

The second vulnerability, Overpatch, targets the open-source Codex CLI when running in “workspace-write” mode. Under normal operation, workspace-write mode restricts file modifications strictly to the active project folder, preventing shell commands or file operations directed at external directories such as user home paths or system trees.

Researchers bypassed this boundary by targeting Codex’s internal patch application tool, apply_patch. The utility contained a permission handling flaw: when applying a multi-file patch, apply_patch expanded write permissions to include the parent directory of every path listed in the patch set.

By crafting a patch file containing two separate modifications, an attacker could selectively elevate write permissions:

1. A dummy change referencing a file inside /tmp. Because /tmp sits directly off the root directory (/), referencing it caused apply_patch to grant write permissions across the root of the file system.
2. A secondary change targeting a symlink pointing into the host user’s home directory (such as ~/.zshrc).

If the patch contained only the home directory symlink, Codex’s path validation logic rejected the operation. But when paired with the dummy /tmp modification, the broad root-level permission granted by the first line allowed the second modification to pass. The next time the targeted developer opened a terminal shell, .zshrc executed the appended host payload completely outside the AI sandbox.

Architectural Risks in AI Agent Sandboxes

Both Heapjack and Overpatch demonstrate a recurring architectural mistake in local AI software design: placing security boundary enforcement inside the same untrusted domain being evaluated.

In Heapjack, the secret token intended to prove process trust was stored in the same memory heap accessible to untrusted execution scripts. In Overpatch, apply_patch derived its permission boundaries dynamically from untrusted input supplied within the patch payload itself. This design pattern—relying on software constructs like V8 context isolation to act as hard security perimeters—frequently fails because V8 contexts were engineered for scope isolation, not adversarial memory segregation.

Similar design weaknesses have surfaced across other developer-focused AI tools, including Cursor, Gemini CLI, and Google’s Antigravity framework. As organizations integrate autonomous coding agents into active development workflows, attackers are shifting focus toward repository poisoning and prompt injection. If an attacker can trick an agent into processing a crafted repository, any sandbox flaw that yields host command execution turns routine code exploration into a full developer workstation compromise.

What To Do

Defenders and software engineers using OpenAI Codex tools should verify that their installations are updated to patched versions immediately:

• Codex Desktop: Update to build 26.818.21641 or later to address the node_repl heap memory leakage issue.
• Codex CLI: Upgrade the open-source CLI package to version 0.149.0 or later to fix the apply_patch path traversal logic.

Given that Codex Desktop automatically injects global configuration entries into ~/.codex/config.toml, security teams should inspect developer workstations for outdated installations and ensure automated update mechanisms are enabled for all AI development tooling.