Openai Codex Sandboxto Run Commands on Host

Researchers escaped OpenAI's Codex sandbox two ways, one running commands on a developer's machine from its most locked-down mode. OpenAI has patched both. 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.

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 Heapjack attack path (​​​​​Accomplish.ai) 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.