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/
Top comments (1)
"The path triggers even under the most stringent read-only mode" is the detail that should worry people. Read-only was doing reputational work here, not security work.
The root cause is the one worth naming: trusted and untrusted code sharing process memory means the boundary is a convention inside a single address space. No amount of mode strictness fixes that, because the token is readable by construction.
This is the case for a boundary that isn't a process boundary. Each Cube on Krova Cloud is a Firecracker microVM with its own kernel, plus a per-cube jailer sandbox with its own unprivileged user, chroot and PID namespace, so even a hypervisor escape lands in an isolated sandbox rather than as root on the host.
Where that genuinely doesn't help, and I'd rather say it than let it slide: outbound access is open. If an agent reads a token and posts it somewhere, a microVM doesn't stop the exfiltration. It contains what the code can reach on the machine, not what it can send out.
Do you think read-only mode gave users false assurance here, or was the documentation honest about its scope?