Reading a repo was enough to break out of Codex

Codex Desktop's strictest setting is read-only: the agent looks at your code and touches nothing. Oren Yomtov of Accomplish AI found that pointing it at a malicious repository in exactly that mode was enough to run commands on the host, as Bleepingcomputer reports.

At a glance

• Oren Yomtov of Accomplish AI reported two separate escapes, Heapjack in Codex Desktop and Overpatch in Codex CLI, on August 12, 2026, and OpenAI shipped fixes for both within eight days.
• Heapjack photographs the Node.js memory heap to brute-force an authorization token, while Overpatch talks apply_patch into granting write access to the disk root through a path named /tmp.
• Fixes landed in Codex Desktop build 26.818.21641 and Codex CLI 0.149.0, and the advice to developers is to update to those versions or later before trusting agent output on untrusted repos.

If you have not been following the Codex sandbox work, OpenAI built its own isolation layer for Windows rather than lean on what the OS ships. According to InfoQ, it evaluated Windows Sandbox and Mandatory Integrity Control and ruled out Windows Sandbox because Codex needs direct access to a developer's repositories and tools. InfoQ also reports that before this work, users faced a tradeoff between approving nearly every agent action and granting unrestricted system access.

Heapjack pulls an authorization token out of a shared Node.js heap

Codex Desktop uses a component called node_repl, which the app writes into the shared config file. It runs trusted and untrusted JavaScript inside the same Node.js process, and one process means one memory heap.

That heap holds a random authorization token. Untrusted code snapshots the heap with v8.getHeapSnapshot(), brute-forces the token out of the dump, then uses it to push commands down the trusted pipe to the parent process, which is not sandboxed.

The trigger is unremarkable: have Codex analyze a malicious repository. The escape works in the strictest read-only sandbox mode, the one meant to forbid writes entirely. OpenAI fixed it in Codex Desktop build 26.818.21641.

Overpatch turns a /tmp path into write access to the disk root

Overpatch goes after Codex CLI and its apply_patch tool. apply_patch works out write permissions from the paths inside the patch, which the attacker supplies: it grants write access to the parent folder of any path named there, instead of checking that path against the workspace boundary.

Name /tmp and you get write access to the root of the disk. Yomtov combined that with a symlinked write to .zshrc, appending a line to the shell startup file in the home directory. The line runs unsandboxed the next time a terminal opens.

The result is an escape from workspace-write, the mode that keeps an agent inside the project folder. The fix is Codex CLI 0.149.0.

Why does a memory snapshot leak a secret?

Because the secret lives in the same memory everyone else can read. Netdata describes the Node.js heap as the place where all dynamic data sits, objects, arrays, strings and closures, and since almost everything in JavaScript is an object, it is the largest pool of memory that running code shares.

Leapcell defines a V8 heap snapshot as a point-in-time photograph of that heap, capturing every object, its type, its size and its references, and notes that generating one pauses the application while V8 serializes the whole heap into a JSON-like dump. Picture an open-plan office where someone is allowed to photograph the entire room for an inventory. The sticky note on the next desk ends up in the shot as well.

The write-up we have does not say whether either bug was used against anyone before the patches landed, or how many installs sat exposed during the eight days between report and fix. On our reading, the uncomfortable part is that Heapjack worked in read-only mode, the setting you pick precisely when you do not trust the code in front of you.

Before your next untrusted repo Two build numbers are the whole remedy on offer: Codex Desktop 26.818.21641 and Codex CLI 0.149.0. What is not stated is whether OpenAI rebuilt the permission model behind apply_patch or closed the specific paths Yomtov walked through, and no date is given for a fuller technical account. Whether other Codex components still run trusted and untrusted code in one process remains open.