Two sandbox escapes let OpenAI Codex run commands on a developer’s host
Researchers found two ways out of OpenAI’s Codex sandbox, one capable of running commands on a developer’s machine from the most locked-down mode, with no prompt and nothing on screen. Update Codex and never run a coding agent with access to the Docker socket or your home directory.
August 12, 2026. Oren Yomtov, a researcher at Accomplish AI, reports two flaws in OpenAI’s Codex sandbox. September 20, 2026. The technical details go public, both flaws having been fixed within eight days. 26.818.21641. The Codex Desktop build that fixes the more serious one. Why it matters: opening someone else’s repository in Codex and asking a question about the code was enough to hand the repository’s author unsandboxed command execution on your machine.
Heapjack: reading the token from shared memory
The more serious of the two flaws, dubbed Heapjack, turns a routine action into remote code execution. Codex is OpenAI’s coding agent, available as a command-line tool and a desktop app. Like its rivals, it runs the model’s actions inside a sandbox so untrusted code cannot touch the wider system. Heapjack defeats that boundary from the inside.
The target is 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 holding two separate JavaScript contexts. One is trusted and contains OpenAI’s own code. The other is untrusted and runs the agent’s code. The trusted context proves its identity by presenting a random token generated fresh on each run. The problem: 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 attack is then mechanical. The untrusted code takes a heap snapshot 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 reveals the token is right. Once the token is known, the untrusted code writes its own request onto the same pipe the trusted context uses to talk to the native, unsandboxed parent process. The parent checks the token, sees a valid one, and does the work.
The proof of concept used the system open command to launch an application entirely outside Codex’s process tree. The same access reaches any Unix socket — the Docker daemon socket being the obvious target — plus a tool for editing the global config file. All of this runs in read-only mode, the strictest sandbox, where the agent is not supposed to write anything at all.
Overpatch: writing outside the folder via a path’s parent
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 patch tool, apply_patch, to write there anyway.
apply_patch 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 names /tmp and does nothing useful except widen the permission; the other 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 enforcement mechanism computes its own permissions from attacker-supplied input, then obeys what it just computed.
The symlink is the tell. The permission system reasons about paths, not about what those paths point to, so a symlink into the home directory defeats the write boundary without breaking the rules. It is the same class of confusion that has haunted every path-based sandbox, from web upload filters to container volume mounts.
The same mistake, twice
Both bugs share a shape: the enforcement mechanism lived inside the thing it was supposed to be enforcing. apply_patch worked out its 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.
A comment under Yomtov’s post condenses the flaw into a phrase worth keeping: “V8 contexts isolate globals, not memory, so the sandbox was really a promise the heap never agreed to.” Another reader called the trust boundary “a room divider” — it delineates, but it stops nothing.
A class of problem, not an isolated incident
The flaw is not unique to OpenAI. In July 2026, researchers at Pillar Security demonstrated the same idea across Cursor, Codex, Gemini CLI, and Google’s Antigravity: an agent that stays inside its sandbox writes a file that a trusted tool outside the sandbox later runs. The defect is structural, rooted in how these agents nest an untrusted interpreter inside trusted tooling.
What is new in Heapjack is that it does not rely on a chain of tools, but on a design flaw in the sandbox itself — a trust secret placed in memory shared with untrusted code. That is an error mature sandboxes, built on process or virtual-machine boundaries, do not make.
For a user, the lesson is direct: these agents download and run code you did not write — from an unknown repository, a model suggestion, a library. The sandbox is your last line of defense, and it is, at best, young.
What this changes for anyone running a coding agent
OpenAI fixed Heapjack in Codex Desktop build 26.818.21641 and Overpatch in Codex CLI 0.149.0. Users should move to those versions or later. Yomtov credits OpenAI with resolving both flaws within eight days of his report.
But the update is not enough. As long as these sandboxes share memory or derive their permissions from untrusted input, the boundary remains fragile. The minimum precautions are to never run a coding agent with access to the Docker socket, SSH keys, or a home directory containing sensitive configuration. An agent opening a third-party repository should run in a disposable environment with no access to the rest of the machine.
For most teams, that means running the agent inside a throwaway container or virtual machine, mounting only the specific repository being worked on, and keeping credentials — cloud tokens, SSH keys, git credentials — out of reach of the agent’s process. It also means reviewing what an agent is about to run before it runs it, especially when the repository is not yours.
The deeper question outlives the patch: a tool that executes untrusted code on your machine, with your identities and your access, is a full-fledged attack channel. That the most locked-down mode — read-only — was enough for Heapjack shows that a mode’s severity guarantees nothing when the boundary itself is porous.
Verdict
If you use Codex, update immediately to Codex Desktop 26.818.21641 and Codex CLI 0.149.0 or later, and treat any earlier version as exposed. If your teams use coding agents, isolate their execution: no Docker socket, no SSH keys, no real home directory, and a disposable environment for any third-party repository. If you build a tool that runs untrusted code, remember the rule Heapjack illustrates: the trust boundary must never share memory with what it isolates, and the enforcement mechanism must never compute its permissions from attacker-controlled input.