Reading a repo was enough to break out of Codex

OpenAI patched two Codex sandbox escapes within eight days of Oren Yomtov of Accomplish AI reporting them on August 12. One of them, Heapjack, gave a malicious repository command execution on the host even in Codex Desktop’s strictest read-only mode. If you open code you didn’t write in Codex, the fixes are in Codex Desktop build 26.818.21641 and Codex CLI 0.149.0, and earlier builds of each still carry their bug.

BleepingComputer reported the research on September 20. Yomtov’s write-up on the Accomplish blog walks through both chains. Heapjack starts in node_repl, which Codex Desktop writes into the global ~/.codex/config.toml as an [mcp_servers.node_repl] block at install, with no opt-in and no setting to turn it off. Because that config file is shared, the plain codex CLI on the same machine gets the tool too.

Heapjack, from a read-only session

node_repl is an MCP server (an external tool wired into the agent) built as a native Rust program. It runs unsandboxed and can open applications, connect to unix sockets and write the config file. It starts a Node process through the Codex sandbox, and that process holds two V8 vm contexts. The trusted one runs OpenAI’s code and holds a secret token. The untrusted one runs whatever JavaScript the agent produces. Both send requests to the Rust parent as JSON lines on stdout, over a single pipe they share.

The token is a random value generated fresh on every run, which counted for little once both contexts sat in one Node process, one V8 isolate and one heap. Untrusted code takes a heap snapshot with v8.getHeapSnapshot() and tries every UUID-shaped string in it. The parent tells it when it has the right one: a wrong token comes back as not authorized, while the right token with a bad argument returns a real validation error.

With the token, the parent runs the system open command, so launchd starts the application unsandboxed, outside Codex’s process tree. The same token can connect to any unix socket, a Docker daemon socket being the obvious target, and exposes a tool for editing the global ~/.codex/config.toml. All of it ran in read-only mode, and Codex never asked for approval. The trigger is ordinary use: clone a repo, open it in Codex in read-only mode and ask a question, and whoever wrote the repository gets unsandboxed command execution, with no prompt and nothing on screen.

Codex isn’t the only agent where opening a repo in the strictest mode has reached the host: a single unhardened git call did the same to Claude Code’s sandbox.

How Overpatch widens a patch

Overpatch targets Codex CLI in workspace-write mode, where the agent may write only inside the workspace folder and a shell command that tries $HOME is refused. The weak point is apply_patch, the file-editing tool the Codex harness gives the agent. It derives write permissions from the paths an attacker supplies: each path in a patch grants write access to its parent folder, so naming /tmp grants write access to /.

The exploit patch has two changes. One appends a line to .zshrc through a symlink into $HOME. The other names /tmp and does nothing. It fails, because a file cannot be written over a directory, and is there only to widen the grant. Without it the .zshrc write is refused. With it, the line lands and runs unsandboxed in the next terminal opened. Accomplish says this works in the normal agent mode with no approval prompt.

OpenAI’s fix, merged August 20, filters out already-writable targets before deriving additional parent permissions, General Analysis says, and the 0.149.0 release came out the same day. Its regression tests include workspace-directory targets and a symlink leading outside the workspace.