Escaping the OpenAI Codex sandbox: two flaws that ran commands on the developer's machine

Oren Yomtov of Accomplish AI has described two ways to break out of the sandbox in Codex — OpenAI's coding agent, available as a command-line tool and a desktop app. Like its rivals, Codex runs the model's actions inside a sandbox so untrusted code cannot touch the wider system. Both techniques defeat that boundary from the inside. The flaws were reported to OpenAI on August 12 and fixed within eight days.

Heapjack

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

The target is a component called node_repl, which Codex Desktop writes into the shared ~/.codex/config.toml file at install time. There is no way to turn it off, and because the entry lives in the shared config, plain CLI users inherit the same tool without ever being asked.

node_repl runs a single Node.js process holding two JavaScript contexts: a trusted one with OpenAI's own code, and an untrusted one with the agent's code. The trusted side proves itself with a random token generated fresh on each run. The problem is that both contexts live in one process and share one memory heap, so the token is just a string the untrusted side can read.

The untrusted code takes a heap snapshot with v8.getHeapSnapshot() and tries every string shaped like a UUID. A wrong guess returns "not authorized"; the correct token with a bad argument returns a real validation error, revealing the right key. With the token, the code writes its own request onto the same pipe the trusted context uses to talk to an unsandboxed parent process. The parent checks the token and does the work. The proof of concept used the system open command; the same access reaches any Unix socket — a Docker daemon socket being the obvious target. All of this runs in read-only mode, the strictest setting, where the agent is not supposed to write anything at all.

Overpatch

The second flaw sits in the open-source Codex CLI. In workspace-write mode the agent may only write inside the project folder. The researchers got Codex's own patch tool, apply_patch, to write elsewhere: it 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 two changes — one useless one naming /tmp that merely widens the permission, and one that appends a line to .zshrc through a symlink into the home directory. Remove the first and the write is refused. Keep it, and the next terminal the developer opens runs the attacker's line unsandboxed.

The same mistake

Both bugs share a shape: the enforcement mechanism lived inside the thing it was meant to enforce. 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. The bug class is not new — in July 2026 Pillar Security demonstrated the same idea across Cursor, Codex, Gemini CLI and Antigravity.

OpenAI fixed Heapjack in Codex Desktop build 26.818.21641 and Overpatch in Codex CLI 0.149.0. Users should update to those versions or later.

Source: Bleeping Computer