Researchers escape OpenAI Codex sandbox to run commands on host

Security researchers found two ways out of the OpenAI Codex sandbox, one of them capable of running commands on a developer's machine from Codex's most locked-down mode, with no approval prompt and nothing shown on screen.

Both flaws were reported to OpenAI on August 12 and fixed within eight days, according to Oren Yomtov of Accomplish AI.

The more serious of the two, which the researchers call Heapjack, turns a routine action into remote code execution: open someone else's repository in Codex, ask it a question about the code, and whoever wrote that repository gets unsandboxed command execution on your computer.

Codex is OpenAI's coding agent, available as a command-line tool and a desktop app. Like rival agents, it runs the model's actions inside a sandbox so that untrusted code cannot touch the wider system. Both escapes work by defeating that boundary from the inside.

Heapjack

The Heapjack technique, as described in Yomtov's writeup, targets a component called node_repl, which Codex Desktop writes into the global '~/.codex/config.toml' file at install time.

There is no opt-in and no setting to turn it off, and because the entry lives in the shared config, plain Codex CLI users inherit the same tool without ever being asked.

node_repl runs a single Node.js process that holds two separate JavaScript execution contexts. One is trusted and contains OpenAI's own code. The other is untrusted and runs the agent's code. The trusted context proves it is trusted by presenting a random token generated fresh on each run.

The problem is that both contexts live in one Node process and share one memory heap, so the token is just a string sitting in memory the untrusted side can read.

The untrusted code takes a snapshot of the heap with 'v8.getHeapSnapshot()' and tries every string shaped like a UUID. A wrong guess returns "not authorized." A correct token with a bad argument returns a real validation error, which tells the attacker the token is right.

With the token, the untrusted code writes its own request onto the same pipe the trusted context uses to talk to a native, unsandboxed parent process.

The parent checks the token, sees a valid one, and does the work. The proof of concept used the system's 'open' command to launch an application outside Codex's process tree entirely. The same access reaches any Unix socket, a Docker daemon socket being the obvious target, and a tool for editing the global config file.

All of this runs at read-only, the strictest sandbox mode, where the agent is not supposed to write anything at all.

Overpatch

The second flaw, Overpatch, sits in the open-source Codex CLI. In workspace-write mode, the agent may only write inside the project folder, and a shell command aimed at the home directory is refused.

The researchers got Codex's own patch tool, apply_patch, to write there anyway.

The tool grants write access to the parent folder of each path named in a patch. Name '/tmp', and it grants write access to the root of the disk.

The working exploit uses a patch with two changes: one that names '/tmp' and does nothing useful except widen the permission, and one that appends a line to '.zshrc' through a symlink into the home directory.

Remove the first change and the write is refused. With it, the next terminal the developer opens runs the attacker's line unsandboxed.

The same underlying mistake

Both bugs share a shape: the enforcement mechanism was living inside the thing it was supposed to be enforcing. apply_patch worked out its own permissions from attacker-supplied input. node_repl kept the secret separating trusted from untrusted code in the same memory as the untrusted code.

In each case the sandbox was told, from the inside, to let something through.

The class of bug is not new. In July 2026, Pillar Security researchers demonstrated the same idea across Cursor, Codex, Gemini CLI and Google's Antigravity, where an agent that stays inside its sandbox writes a file a trusted tool outside the sandbox later runs.

Reacting to Yomtov's post on X, one commenter wrote that "V8 contexts isolate globals, not memory, so the sandbox was really a promise the heap never agreed to." Another called the trust boundary "a room divider." The default-enabled behavior drew its own scrutiny, with one asking why a privileged token was reachable from untrusted JavaScript at all.

What to do

OpenAI fixed Heapjack in Codex Desktop build 26.818.21641 and Overpatch in Codex CLI 0.149.0, according to Accomplish.

Users should update to those versions or later. Yomtov credited OpenAI with resolving both issues within eight days of his report.

BleepingComputer reached out to OpenAI for comment prior to publishing.