OpenAI Codex Sandbox Escapes Let Untrusted Code Run Commands on Developer Machines

Security researchers have discovered two vulnerabilities that can escape the OpenAI Codex sandbox. One of the flaws allows commands to run on a developer’s machine from Codex’s most restrictive mode, without authorization prompts or visible activity.

Accomplish security researcher Oren Yomtov said both vulnerabilities were reported to OpenAI on August 12 and fixed within eight days.

The more serious flaw, which researchers call heapjacking, can turn routine coding tasks into remote code execution. When a user opens someone else’s repository in Codex and asks questions about its code, the repository’s creator could potentially run unsandboxed commands on the user’s computer.

OpenAI Codex is a coding agent available as both a command-line tool and a desktop application. Like competing coding agents, it executes model-generated actions inside a sandbox designed to prevent untrusted code from affecting the wider system. Both vulnerabilities bypass that protection from within the sandbox.

Heapjacking: Escaping the Codex Desktop sandbox

For more information about the heapjacking technique, see Yomtov’s technical write-up.

The attack targets a component called Node Ripple, which Codex Desktop writes to ~/.codex/config.toml during installation.

There is no opt-in or disable setting for the component. Because the entry is stored in shared settings, users of the Codex CLI inherit the same tools without being asked.

Node Ripple runs a single Node.js process containing two separate JavaScript execution contexts. One context is trusted and contains OpenAI’s proprietary code. The other is untrusted and executes the agent’s code. The trusted context proves its legitimacy by presenting a newly generated random token during each execution.

The problem is that both contexts run in the same Node.js process and share one memory heap. As a result, the token is simply a string in memory that untrusted code can read.

Untrusted code takes a snapshot of the heap using v8.getHeapSnapshot() and searches for strings that resemble UUIDs. If the token guess is wrong, the system returns “Not allowed.” However, supplying an invalid argument with a valid token returns a different validation error, allowing the attacker to determine when the token has been found.

With the token, untrusted code can write its own requests to the same pipe that the trusted context uses to communicate with the native, nonsandboxed parent process.

The parent process checks the token, sees a valid value, and performs the requested operation. In their proof of concept, the researchers launched an application outside the entire Codex process tree using the system’s open command. The same access can reach Unix sockets, including the Docker daemon socket, as well as tools that edit global configuration files.

The researchers said the attack works even when Codex runs in read-only mode, the strictest sandbox setting in which the agent cannot write files.

Overpatch: Codex CLI vulnerability bypasses workspace restrictions

The second vulnerability, dubbed Overpatch, affects the open-source Codex CLI. In workspace write mode, the agent is supposed to write only inside the project directory, while shell commands targeting the user’s home directory are rejected.

However, the researchers used Codex’s own apply_patch tool to write outside the permitted location.

The tool grants write access to the parent directory of each path specified in a patch. By naming /tmp, an attacker can expand the permitted write area to the root of the disk.

A working exploit uses a patch containing two changes. The first references /tmp and performs no useful action other than expanding permissions. The second adds a line to .zshrc through a symlink to the user’s home directory.

If the first change is removed, the write is rejected. When both changes are included, the attacker’s line can run unsandboxed the next time the developer opens a terminal.

Both flaws broke the Codex trust boundary

Both vulnerabilities share the same fundamental design mistake: a mechanism intended to enforce a security boundary was controlled from inside that boundary.

Apply_patch calculated its own privileges using input supplied by the attacker. Meanwhile, Node Ripple stored the secret separating trusted and untrusted code in the same memory heap accessible to untrusted code.

In both cases, the sandbox was instructed to pass something through from within the sandbox itself.

This type of vulnerability is not new. In July 2026, Pillar Security researchers demonstrated a similar technique affecting Cursor, Codex, Gemini CLI, and Google’s Antigravity. An agent operating inside a sandbox writes a file, after which a trusted tool outside the sandbox executes it.

One commenter responding to Yomtov’s post on X wrote: “The V8 context separates globals, not memory, so the sandbox was actually a promise that the heap would never agree to.” Another commenter described the issue as a “trust boundaries” and “room partition” problem.

The default-enabled behavior has also drawn independent scrutiny, including questions about how privileged tokens can be accessed by untrusted JavaScript.

How to protect against the Codex sandbox escapes

According to Accomplish, OpenAI fixed the heapjacking vulnerability in Codex Desktop build 26.818.21641 and the Overpatch vulnerability in Codex CLI 0.149.0.

Users should update Codex Desktop and Codex CLI to these versions or later. Yomtov credited OpenAI with resolving both issues within eight days of receiving the reports.

BleepingComputer reached out to OpenAI for comment before publication.

Join Mikko Hypponen and security leaders from the NFL, Chanel, and Atlassian for a 2-hour digital summit about what will change with AI speed attacks, what defenders should stop doing, and how to verify, decide, fix, and revalidate at machine speed.

Please reserve your seat