A single unprivileged user on a shared Windows machine can intercept OpenAI Codex CLI's sandbox communication, inject malicious instructions into the AI agent, and walk away with another developer's cloud credentials, including persistent refresh tokens. Security researchers at Cymulate found that Codex's Windows sandbox used named pipes with overly permissive access controls, allowing any local account to hijack the AI's output stream and impersonate the legitimate user.

How Did This Vulnerability Work?

When Codex runs a command on Windows, it creates three named pipes (stdin, stdout, and stderr) to communicate between the main process and a restricted sandbox runner. The pipes were created with a security descriptor that granted full control to "Everyone," the Windows principal representing any account on the machine. Because the pipes accepted only a single connection, an attacker could connect first and intercept the output before the legitimate sandbox runner arrived.

The attack required no malware, no privilege escalation, and no internet connection. An attacker simply monitored the pipe namespace every 50 milliseconds, waiting for a victim to run a Codex command. Once the pipes appeared, the attacker connected to the stdout pipe, spoofed the sandbox's response, and fed Codex a convincing lie. Within 30 seconds, the attacker possessed the victim's OpenAI API tokens, including a refresh token that remained valid long after the session ended.

"One unprivileged user could read another user's cloud credentials and impersonate their AI assistant. The fix is shipped; the lesson that AI tooling is being adopted faster than its security model is maturing, is not going anywhere," stated the Cymulate Security Research Team.

Ilan Kalendarov, Security Research Team Lead; Ben Zamir, Security Researcher; Elad Beber, Security Researcher at Cymulate

Who Is Actually at Risk?

The vulnerability affects developers who run Codex CLI on shared or multi-user Windows environments, including terminal servers, virtual desktop infrastructure (VDI), Remote Desktop Protocol (RDP) jump boxes, and shared build machines. These are common in enterprise settings where multiple engineers access the same physical or virtual machine. The attack vector is local only, meaning the attacker must have an account on the same Windows host, but that account requires no special privileges.

The vulnerability carried a CVSS severity score of 8.5 out of 10, classified as "High," with impacts spanning cross-user credential theft, output spoofing, AI command injection, and potential denial of service.

Steps to Secure Shared AI Agent Environments

• Scope Pipe Access: Restrict named pipe security descriptors to only the sandbox user and the main process owner, not "Everyone." OpenAI shipped fixes in pull requests #14139 and #19283 that scoped runner pipe transport to the sandbox user and added client-identity verification.
• Implement Capability Scoping: Define explicit boundaries for what files, commands, and network endpoints an agent may access. Pair sandbox enforcement with approval flows when agents must cross those boundaries.
• Distinguish Local from Shared Agents: Treat "local" developer-configured agents differently from "shared" managed agents. For shared agents, decompose the agent harness from the web-service tools it calls to reduce blast radius.
• Add Observable Baselines: Deploy syscall allowlists, audit logs, and observable baselines for progressive enforcement so teams can detect anomalous agent behavior before it escalates.
• Use Platform-Native Sandboxing: Leverage OS-provided sandbox primitives such as bubblewrap on Linux or Windows Sandbox features rather than relying on application-level isolation alone.

What Does This Mean for the Broader AI Agent Ecosystem?

This vulnerability is part of a larger pattern: AI coding agents are being adopted faster than their security models mature. The Cymulate research team investigated how AI agents keep their promises, particularly the implicit pledge that sandboxes contain the blast radius of dangerous code. If an agent cannot protect its own execution boundary, the question becomes urgent: why would anyone trust it to protect the developer's environment ?

The industry is now selling AI agents as security assistants, yet foundational isolation mechanisms remain fragile. Sandboxing is rapidly becoming a core engineering requirement for production agentic workflows, with vendors like OpenAI, Cloudflare, and Kubernetes SIG Apps delivering sandbox primitives and guidance. OpenAI introduced native sandbox execution and a SandboxAgent harness in its Agents SDK in April 2026, while Cloudflare released the Dynamic Worker Loader in open beta in March 2026 for spawning ephemeral sandboxes inside Cloudflare Workers.

Three dominant sandbox families are emerging: heavyweight containers and microVMs offer strong OS-level isolation but impose higher startup latency and memory overhead; lightweight worker sandboxes provide near-instant instantiation and tight capability scoping; and platform-integrated sandboxes like Kubernetes' proposed Sandbox CustomResourceDefinition (CRD) target operational concerns for long-lived, stateful agents.

OpenAI shipped fixes for the Codex CLI vulnerability, but the underlying lesson persists: practitioners building agentic workflows must treat the agent's local inter-process communication as part of the attack surface. If developers run AI coding agents on shared or multi-user Windows hosts, the local IPC layer is no longer an implementation detail; it is a security boundary that requires the same rigor as any other trust boundary in the system.