Opening a stranger's repo in Codex gave the repo author your shell

Oren Yomtov of Accomplish AI disclosed two Codex sandbox escapes on September 20, and the first one bothers me more than any agent CVE I've read this month.

BleepingComputer has the writeup. Heapjack abuses node_repl, a helper that Codex Desktop writes into the global ~/.codex/config.toml at install. No opt-in. No off switch. The trusted and untrusted JavaScript contexts share one Node heap, so untrusted agent code calls v8.getHeapSnapshot(), brute-forces the UUID-shaped auth token out of the snapshot, and then writes requests directly onto the pipe to the unsandboxed native parent process. From read-only mode. With no approval prompt.

Read that again. Read-only mode. No prompt.

The second one, Overpatch, is simpler and dumber. Codex CLI's apply_patch grants write access to the parent folder of every path a patch names. Name /tmp and you've opened the disk root. A second hunk appends to .zshrc through a symlink and now you own every future shell.

Reported August 12, fixed in eight days. Patched in Codex Desktop build 26.818.21641 and Codex CLI 0.149.0. OpenAI moved fast, credit where it's due.

The thing I can't stop turning over is the install-time config write. A helper that gives untrusted code a path to the unsandboxed parent got added to every user's global config with no announcement and no toggle. Nobody chose that. Nobody could have audited it without reading their own config.toml and knowing what node_repl meant.

Every one of us opens repos we didn't write. That's the job. I pull a library to see how it handles a thing, I clone somebody's example to check whether their approach is better than mine, I open a candidate's take-home. Under these bugs, each of those was handing shell to the author.

Concrete actions. Check your Codex versions and upgrade past the fixed builds. Then open ~/.codex/config.toml and read it, because you didn't write all of it. And separate the machine where you open unknown code from the machine that has your cloud credentials on it, which is advice I've been ignoring myself and am about to stop ignoring.

There's a broader read here about harness sandboxes. Two things this week cut the same direction: PR #5139 in openai-agents-python fixed macOS sandbox profiles granting read access to host PATH directories the child process no longer had, so narrowing a child's PATH to /usr/bin:/bin still left an unrelated host virtualenv readable. And Codex PR #46999 replaced tool allowlists with a ToolPolicy captured once at startup, specifically because allowlists couldn't express sandbox restrictions and later extension-state changes could relax them. The sandbox stories all have the same shape: the boundary was described in one place and enforced in another, and the gap between them was the bug.