Credentials in the Agent's Reach: The Codex Memory-Sharing Issue

Researchers reported a Codex sandbox escape in which untrusted code generated by the AI agent read authentication tokens from a shared process memory region in the Node.js utility bundled with Codex Desktop, then forged requests to external native programs to achieve a full sandbox escape even under strict read-only mode. The flaw, reported to OpenAI on August 12, 2026, was fixed in Codex Desktop 26.818.21641 and later, while a separate CLI patching utility issue was resolved in Codex CLI 0.149.0. No CVE identifiers were assigned, and the mechanism was not independently reproduced.

Of the two Codex sandbox escape issues reported on September 21, 2026, the second deserves closer reading. It is not about a file path or a permission flag. It is about authentication tokens sitting in memory that untrusted code could read. The issue involves the Node.js tool bundled with the Codex desktop edition. That utility executes both trusted code and code generated by the AI agent, and both share a portion of the process memory space. The researchers describe untrusted code extracting authentication tokens directly from that shared region, then forging requests and submitting them to external native programs for processing. Because those programs can launch applications, connect to local Unix sockets, or modify global configuration files, the described outcome is a full escape of the Codex sandbox. The report states the path triggers even under the most stringent read-only mode and requires no manual user approval. A user need only open a repository containing malicious content, which lets the repository author influence agent behaviour through prompt injection. Codex Desktop 26.818.21641 and later resolved it. The first issue, in the CLI patching utility, was resolved by Codex CLI 0.149.0, released August 21, 2026. Both flaws were reported to OpenAI on August 12, 2026. No CVE identifiers appeared in the source material, and the mechanism was not independently reproduced here. Isolation models usually assume that separate code paths are 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 because they are short-lived credentials with real authority. 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 external native programs is the step that turns a read into an action. The first implication is that credential scope matters more than process isolation alone. An agent that holds narrowly scoped, short-lived tokens limits what a memory read is worth. An agent holding broad, long-lived credentials turns a single read into a durable problem. The second is that 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 means the mode governs what the agent is asked to do, not what the underlying process can reach. The third is that repository provenance is a control. The reported precondition is a user opening a repository containing malicious content. Treating untrusted repositories as hostile input, rather than as ordinary working material, addresses the delivery step directly. Codex runs primarily on developer workstations, which external scanners cannot reach. A search for app="Codex" returned 164 indexed instances on September 21, 2026, but that figure describes internet-reachable hosts rather than the population at risk from a memory-sharing flaw. The honest conclusion is that this issue is addressed by inventory and version control, not by external measurement. Knowing which hosts run Codex Desktop below 26.818.21641 is the actionable fact.