OpenAI's Codex Sandbox Let Attackers Run Commands on Your Machine Just by Opening a Repo

Opening a stranger's code in OpenAI's Codex was enough to hand that stranger control of your computer. Security researchers found two ways out of the Codex sandbox, and the more dangerous one worked from the tool's most locked-down mode with no approval prompt and nothing shown on screen.

Codex is OpenAI's coding agent, sold 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 reach the rest of the system. Both escapes beat that boundary from the inside.

The worse one is called Heapjack. The attack path is short and ugly: open someone else's repository in Codex, ask a question about the code, and whoever wrote that repository gets unsandboxed command execution on your machine.

Heapjack targets a component called node_repl that Codex Desktop writes into the global ~/.codex/config.toml file at install time. There is no opt-in and no switch to turn it off, and because the entry sits in the shared config, plain Codex CLI users inherit it too. That default-on, no-opt-out design is what turned a niche bug into everyone's problem.

Underneath, node_repl runs a single Node.js process holding two JavaScript contexts, one trusted with OpenAI's code and one untrusted with the agent's. The trusted side proves itself with a random token, but both contexts share one memory heap, so that token is just a string the untrusted side can read. The untrusted code dumps the heap with v8.getHeapSnapshot(), brute-forces the UUID-shaped token, then writes its own request onto the pipe to the native, unsandboxed parent process.

The proof of concept used the system open command to launch an app outside Codex entirely, and Oren Yomtov of Accomplish AI noted the same access reaches any Unix socket. The obvious target there is the Docker daemon socket, which is a straight line from a code question to control of your containers.

The second flaw, Overpatch, lives in the open-source Codex CLI. In workspace-write mode the agent may only write inside the project folder, but the researchers got Codex's own apply_patch tool to write elsewhere by naming /tmp in a patch, which handed it write access to the root of the disk. Combined with a symlink into the home directory, the exploit appended a line to .zshrc so the next terminal the developer opened ran the attacker's code.

Both bugs share one shape. The enforcement lived inside the thing it was supposed to enforce, so the sandbox was told from the inside to let something through. That is the same pattern Pillar Security demonstrated in July across Cursor, Codex, Gemini CLI and Google's Antigravity, where an agent that stays inside its sandbox writes a file a trusted tool outside later runs. Some readers argued the flawed code was AI-written, but nothing in the research ties either bug to how it was built, and OpenAI has not said.

Neither bug is a live 0-day. Yomtov reported both issues to OpenAI on August 12, and the company fixed them within eight days, in Codex Desktop build 26.818.21641 and Codex CLI 0.149.0. An OpenAI spokesperson thanked the researchers and said the fixes shipped in August, with continued work to tighten where agents can write and to expand testing across platforms. Anyone still on an older build should update. The recurring lesson, familiar from earlier cross-account leaks in ChatGPT's own sandbox, is that the agent's guardrails are only as strong as the process that holds their secrets.