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

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.

What was reported

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.

Why shared memory is the interesting part

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.

Practical implications

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.

External visibility and its limits

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.

References

• SecurityOnline.info, "OpenAI Codex Sandbox Escape Vulnerabilities Disclosed," September 21, 2026: https://securityonline.info/openai-codex-sandbox-escape/
• ZoomEye search interface: https://www.zoomeye.ai/