Researchers escape OpenAI Codex sandbox with Overpatch and Heapjack techniques

Security researchers have demonstrated two separate escapes from OpenAI Codex's sandbox, one of which works from the tool's strictest read-only configuration. The writeup, titled "Escaping the OpenAI Codex sandbox, twice" and published by Accomplish AI on September 15, 2026, describes techniques the researchers named Overpatch and Heapjack. A summary on dev.to reports both issues were fixed within eight days of disclosure and that no real-world exploitation has been observed.

Overpatch: widening write permissions through apply_patch

Overpatch targets Codex CLI running in workspace-write mode, where ordinary shell commands are blocked from writing to locations such as the user's home directory.

At the time of the research, the apply_patch tool determined which paths it could write to by looking at the parent directory of each path named inside a patch. The researchers exploited this by including a no-op patch entry that named /tmp as if it were a file. The write failed because /tmp is a directory, but its parent, /, was still added to the permitted write scope, according to the dev.to summary of the research.

With the root directory now allowed, the same patch appended a line to $HOME/.zshrc by way of a symbolic link placed inside the workspace. No warning appears during patch processing, and the injected command runs on the host the next time the developer opens a terminal.

Heapjack: recovering a trust token from a shared V8 heap

Heapjack is the more striking of the two because it works while Codex is in read-only mode, without triggering an approval prompt.

Codex Desktop added a node_repl entry to the global ~/.codex/config.toml file, which also made it available to Codex CLI. That component starts a Node.js process inside the sandbox containing two V8 VM contexts, one trusted and one untrusted, that share the same isolate and heap.

The trusted context attaches a freshly generated random token to requests it sends to the native Rust parent process outside the sandbox. The researchers' untrusted JavaScript took a heap snapshot with v8.getHeapSnapshot() and tested UUID-shaped strings as candidate tokens. Because wrong tokens produce authorization errors while a correct token with invalid arguments produces a validation error, the difference in responses served as an oracle for identifying the real token.

Once recovered, the token let the sandboxed code write JSON Lines requests to the same standard output pipe the trusted context uses, and the native parent processed them as legitimate. The proof of concept launched the macOS open command outside the sandbox. The researchers said the token could also be used to connect to Unix sockets, including a Docker daemon socket, and to invoke the tool that edits the global Codex configuration. They did not report a successful Docker host compromise.

What success enables and what to check

Both paths start from an untrusted repository opened by a developer, with repository content steering the agent's tool use. In Heapjack, even asking a question about a malicious repository could launch host-side applications.

A successful escape opens the door to whatever the host holds: developer credentials, source code, signing keys and cloud sessions, depending on the environment. Indicators defenders can look for include node_repl settings in the global config, symlinks reaching from the workspace into the home directory, unexpected .zshrc modifications, and Unix socket connections from Codex-related processes.

Patches and additional defenses

According to the summary, updating to Codex CLI 0.149.0 or later and Codex Desktop build 26.818.21641 or later addresses both issues. Accomplish AI also runs the agent and its child processes inside a virtual machine boundary separate from the host, ensuring host credentials and Docker sockets are not passed in. That is defense in depth, not a substitute for patching.

Why it matters

Agentic coding tools depend on sandboxing as their core safety promise: the point of read-only mode is that nothing on the host can change. These verified escapes show that promise can fail in subtle ways, from permission logic that trusts patch paths to memory isolation that leaks across a shared heap. As developers routinely point agents at unfamiliar repositories, a malicious repo becomes a direct attack surface against the developer's machine, and vendors and users alike need layered defenses rather than trust in a single sandbox boundary.