Reported Codex sandbox escape let untrusted code read auth tokens from shared memory

What was reported

Two sandbox escape flaws in OpenAI's Codex were disclosed on September 21, 2026, and according to a dev.to write-up drawing on a SecurityOnline.info disclosure, the more serious of the two is architectural rather than a stray file path or a bad permission flag: authentication tokens sitting in a region of process memory that untrusted code could read.

The affected component is the Node.js utility bundled with the Codex desktop edition. That tool executes both trusted code and code produced by the AI agent, and the two share part of the same process memory space. The researchers describe agent-generated code pulling authentication tokens out of that shared region, then forging requests and handing them to external native programs for processing. Because those native programs can start applications, talk to local Unix sockets or rewrite global configuration files, the report characterises the outcome as a full escape of the Codex sandbox.

The path reportedly triggers even under the most stringent read-only mode and requires no manual user approval. The precondition is simply that a user opens a repository containing malicious content, which lets the repository's author steer agent behaviour through prompt injection.

Patch status and timeline

According to the dev.to post, both flaws were reported to OpenAI on August 12, 2026. The first issue, located in the CLI patching utility, was resolved in Codex CLI 0.149.0, released on August 21, 2026. The memory-sharing flaw was fixed in Codex Desktop 26.818.21641 and later versions.

The write-up carries two caveats worth keeping in mind: no CVE identifiers appeared in the material it drew from, and the author did not independently reproduce the mechanism. The underlying disclosure is attributed to SecurityOnline.info.

Working out who is exposed is its own problem. Codex runs mainly on developer workstations, which external scanners cannot reach. A ZoomEye search for hosts labelled "Codex" returned 164 indexed instances on September 21, 2026, but as the post notes, that figure describes internet-reachable machines rather than the population actually at risk from a memory-sharing flaw. The practical response is inventory and version control: the actionable fact is knowing which machines run a Codex Desktop build older than 26.818.21641.

Why shared memory is the weak point

Isolation models generally assume that separate code paths stay separated. Sharing a process memory space breaks that assumption quietly: nothing looks wrong from the outside, no permission is visibly granted, and no prompt appears.

Tokens are the natural target for exactly this kind of flaw. They are short-lived credentials with real authority, and a token read from memory does not need to be cracked or guessed — it can be replayed immediately. The report's description of forging requests to native programs is the step that converts a passive read into an active capability, because those programs can reach the wider system.

Why it matters

The disclosure carries three practical lessons for anyone running coding agents.

First, credential scope matters as much as process isolation. An agent holding tightly scoped, short-lived credentials caps what a memory read is worth; an agent holding broad, long-lived credentials turns a single read into a lasting problem.

Second, read-only mode is not a security boundary in this scenario. The report is explicit that the path triggers under strict read-only mode, which suggests such settings constrain what the agent is asked to do, not the reach of the process underneath.

Third, repository provenance is a control. The reported delivery mechanism is a user opening a repository containing malicious content, so treating untrusted repositories as hostile input rather than ordinary working material addresses the attack at its entry point.

For teams, the immediate step is straightforward: find hosts running Codex Desktop below 26.818.21641 and update them. The broader step is harder — designing agent runtimes so that credentials never live in memory that generated code can reach in the first place.