BleepingComputer Two Sandbox Escapes Let Attackers Run Commands on Codex Machines — One Worked From Full Lockdown
Security researchers at Accomplish AI found two ways out of OpenAI Codex's sandbox. 'Heapjack' extracted a trust token from shared memory to run commands from the strictest read-only mode; 'Overpatch' turned the CLI's patch tool into a disk-wide write primitive. Both were reported August 12 and patched within eight days.
OpenAI’s Codex runs your agent inside a sandbox so untrusted code cannot touch the wider system. Security researchers found two ways out of it — 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.
The flaws were reported to OpenAI on August 12 and fixed within eight days, according to Oren Yomtov of Accomplish AI, who disclosed them this week. Both attack from the inside: the enforcement mechanism was living inside the thing it was supposed to be enforcing.
Heapjack: stealing the token from shared memory
The more serious escape, which the researchers call Heapjack, targets node_repl, a component Codex Desktop writes into the global ~/.codex/config.toml at install time. There is no opt-in and no setting to disable it — 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 containing two JavaScript execution contexts: one trusted, running OpenAI’s own code, and one untrusted, running the agent’s code. The trusted context proves it is trusted by presenting a random token generated fresh on each run. The problem: both contexts share one memory heap, so the token is a string sitting in memory that the untrusted side can read.
The untrusted code takes a heap snapshot with v8.getHeapSnapshot() and tries every string shaped like a UUID until the token validates. With it, the attacker writes its own request onto the same pipe the trusted context uses to talk to a native, unsandboxed parent process. The proof of concept used the system’s open command to launch an application outside Codex’s process tree — and the same channel reaches Unix sockets, a Docker daemon socket being the obvious target. All of this ran in read-only mode, where the agent is not supposed to write anything at all. The practical trigger: open someone else’s repository in Codex, ask about the code, and the repository author gets unsandboxed execution on your machine.
Overpatch: widening the patch tool’s permission window
The second flaw sits in the open-source Codex CLI. In workspace-write mode, the agent may only write inside the project folder. The apply_patch tool, however, grants write access to the parent folder of each path named in a patch — so a patch that names /tmp quietly widens write permission to the root of the disk.
The working exploit pairs that widening change with a second change 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 with no sandbox at all.
Update your versions
OpenAI fixed Heapjack in Codex Desktop build 26.818.21641 and Overpatch in Codex CLI 0.149.0, per Accomplish. In a statement to BleepingComputer, an OpenAI spokesperson said the company addressed both issues in August and is “continually strengthening our sandboxes, with recent updates that tighten controls on where agents can write files.”
The pattern is worth noting. In July, Pillar Security researchers demonstrated a similar inside-out failure across Cursor, Codex, Gemini CLI, and Google’s Antigravity: an agent stays inside its sandbox, writes a file, and a trusted tool outside the sandbox runs it. The sandbox boundary in AI coding agents keeps turning out to be a room divider, not a wall — as one commenter put it, “V8 contexts isolate globals, not memory, so the sandbox was really a promise the heap never agreed to.”