OpenAI patches two Codex sandbox escapes found by researchers

Two newly disclosed Codex sandbox escape techniques show how an AI coding assistant can be pushed outside the protected space it is supposed to stay in, and both were fixed within eight days of being reported. The findings come from Oren Yomtov of Accomplish AI, who reported the flaws to OpenAI on August 12. Codex is OpenAI's coding agent, offered as a command line tool and as a desktop application, and like similar agents from other vendors it is built to carry out the model's actions inside a sandbox, a walled off area that stops untrusted code from touching the rest of the machine. Both of the escapes work by defeating that boundary from the inside rather than by breaking in from outside.

The more serious flaw, which the researchers call Heapjack, turns an ordinary action into remote code execution, which means attacker code runs on the victim's own computer. The path is short: open somebody else's code repository in Codex, ask the agent a question about that code, and the person who wrote the repository ends up with unsandboxed command execution on your machine. According to Yomtov's writeup, the technique targets a component named node_repl, which Codex Desktop writes into the global configuration file at ~/.codex/config.toml at install time. There is no opt in and no setting to switch it off, and because the entry lives in the shared configuration, people who use the plain Codex command line tool inherit the same component without ever being asked.

The reason the escape works is a design decision inside node_repl. It runs a single Node.js process, a runtime for JavaScript programs, that holds two separate JavaScript execution contexts. One of them is trusted and contains OpenAI's own code, and the other is untrusted and runs the agent's code. The trusted side proves that it is trusted by presenting a random token that is generated fresh on every run. The trouble is that both contexts sit in the same process and share the same memory heap, so that secret token is just a string sitting in memory where the untrusted side can read it.

The untrusted code takes a snapshot of the heap with a function called v8.getHeapSnapshot() and then tries every string that looks like a universally unique identifier, or UUID. A wrong guess comes back with a message saying not authorized. A correct token sent with a deliberately bad argument produces a genuine validation error, which tells the attacker the token is the right one. With the token in hand, the untrusted code writes its own request onto the same pipe the trusted context uses to speak 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 completely outside Codex's process tree. The writeup notes that the same access reaches any Unix socket, a Docker daemon socket being the obvious target, and a tool for editing the global configuration file. All of this runs at read-only, the strictest sandbox mode, where the agent is not supposed to be able to write anything at all.

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 every path named in a patch, so naming '/tmp' is enough to grant 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. Keep it, and the next terminal the developer opens runs the attacker's line without a sandbox around it.

Both bugs share the same shape, which is that the enforcement mechanism was living inside the very thing it was supposed to be enforcing. apply_patch worked out its own permissions from input supplied by the attacker, and node_repl kept the secret that separates 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.

This class of bug is not new. In July 2026, researchers at Pillar Security demonstrated the same idea across Cursor, Codex, Gemini CLI and Google's Antigravity, showing an agent that stays inside its sandbox writing a file that 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 described the trust boundary as a room divider. The fact that the node_repl component is enabled by default also drew scrutiny, with one commenter asking why a privileged token was reachable from untrusted JavaScript at all.

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 said it reached out to OpenAI for comment prior to publishing.

For teams that want help reviewing how developer and cloud tools are configured across their organisation, AEU-I provides security-first IT, infrastructure and consulting services.