OpenAI Codex Windows sandbox: what changed after early security failures

OpenAI published its most detailed technical account yet of how the Codex coding agent runs inside a Windows 11 sandbox this week, following months of documented complaints about the earlier implementation. The redesigned OpenAI Codex Windows sandbox uses separate execution identities, OS-level network isolation, and DPAPI-scoped credentials, according to WinBuzzer's coverage of OpenAI's safety post published six days ago. Whether the redesign resolves the original complaints is a separate question, and the answer is incomplete.

A GitHub issue opened in February documented what went wrong first: the sandbox accounts were granted read access not just to active project folders but to C:\Users\ and every subdirectory beneath it. Users in that thread reported SSH workflows breaking, DRM failures in Vivaldi, and child-process access denials in Cricut Design Space all traced back to ACL changes Codex made on installation.

For teams evaluating Codex on Windows 11 now, the question isn't whether it's sandboxed. It's whether the specific gaps that caused those failures have been closed.

What the first Windows sandbox got wrong

Before the March 2026 Windows launch, Codex had no sandbox on Windows at all, per WinBuzzer. When OpenAI shipped one, it used OS-level controls including restricted tokens, filesystem ACLs, and dedicated sandbox users, according to the OpenAI community thread announcing the Windows app. The scope of those ACLs is where things broke down.

The February GitHub issue documented the core problem: the sandbox accounts CodexSandboxOffline and CodexSandboxOnline were granted permissions across the entire C:\Users\ directory tree, not just the folders where Codex was actively running. Some users reported the same accounts were added to entire secondary drives. After uninstalling Codex, stale SID entries remained on ACLs throughout their filesystems the environment stayed dirty even after the tool was gone.

The fallout was functional, not theoretical. SSH workflows broke because Codex had modified permissions on ~/.ssh/config and private key files; OpenSSH on Windows rejects keys with overly broad ACLs, which is a hard failure. One user traced DRM failures in Vivaldi and child-process access denials in Cricut Design Space directly to Codex's ACL changes. Reinstalling the affected applications changed nothing. The problems cleared only after manually removing the Codex-related ACL entries, per the same issue thread.

OpenAI's response at the time: broad read access was unlikely to change in the near term, and users who found it objectionable could switch to an unelevated sandbox mode by editing config.toml. That answer did not land well. Replies in the thread pushed back sharply "broad read access bothers some users" badly mischaracterized what people were actually dealing with, which was an agent with near-total filesystem visibility and no clean path to remove it.

Old vs. new sandbox model:

How the redesigned OpenAI Codex Windows sandbox works

The current architecture separates execution into two dedicated local accounts: CodexSandboxOffline for default operation and CodexSandboxOnline when a user explicitly authorizes broader connectivity, per WinBuzzer. Windows cuts the offline identity off from all outbound traffic at the OS level. That's a hard network boundary, not an application-layer setting that a process can route around.

Before any command reaches a child process, the system works through a four-stage execution path: the setup executable creates sandbox accounts, checks firewall state, stores credentials using DPAPI, then hands off to codex-command-runner.exe, WinBuzzer reports. DPAPI is Windows credential protection, not a separate cloud gate. It binds stored credentials to the local machine's identity, which means sandbox accounts can't usefully exfiltrate them off-device even if a malicious prompt attempts it.

Three constraints define the sandbox's core behavior, per OpenAI's safety post: write access is limited to the active workspace; outbound network access is blocked by default with approved destinations listed explicitly; and the agent must request approval to act outside those boundaries. Higher-risk actions surface to the user rather than being silently permitted or silently blocked.

The groundwork for this was substantial. An alpha pull request merged in late October 2025 introduced the Windows restricted-token sandbox, ACL management, capability SID provisioning, network lockdown, and a Python smoke-test suite covering read-only, workspace-write, and network-denial scenarios (GitHub PR #4905). The current design builds on that foundation.

What the Codex Windows sandbox still doesn't fix

The redesigned sandbox tightens write access and network access meaningfully. Read access is a different story.

Codex can still read broadly across a developer's machine, per WinBuzzer's coverage of OpenAI's documentation. Neither OpenAI's technical post nor available community reporting specifies which paths remain accessible to the sandbox accounts, or whether the C:\Users\ tree exposure from the original complaints has been narrowed. OpenAI's earlier response to the GitHub thread said this was unlikely to change; no public update has reversed that position.

For security teams, this is where the gap lives. A sandbox that controls where an agent writes and what it can reach over the network is meaningfully safer than an unconstrained agent. But an agent that can read freely across a developer's profile directory, including configuration files, credentials stored in user-space, SSH keys, and application data, still represents a significant attack surface if Codex is manipulated into exfiltrating information through an approved network channel or a permitted write path.

OpenAI frames this within a layered model: the sandbox sets hard technical limits, approval policy handles actions outside those limits, and OpenTelemetry-based logging gives security teams visibility into what the agent did and why, according to the safety post. That covers prompts, tool calls, approval decisions, and network allow/deny events, with logs available through the OpenAI Compliance Platform for Enterprise and Edu customers. The telemetry closes the observability gap that raw process logs leave open. It does not close the read-access gap.

What Windows developers and security teams should actually check

The gap between "sandboxed" as marketed and "sandboxed" as experienced on real endpoints has narrowed. The layered model, scoped writes, network isolation, approval gates, and structured logging, is coherent as a framework. Independent validation of the specific claims from the February GitHub issue has not materialized in the public record.

Three things remain unconfirmed: whether broad read access to the user profile tree has been scoped; whether ACL cleanup on uninstall now works cleanly; and whether SSH key permissions are protected from modification. The Codex CLI has been updated continuously, and version 0.130.0 in April included multiple sandbox and Windows fixes, per WinBuzzer. That suggests active remediation rather than a finished product.

Before deploying Codex locally on Windows 11, verify the following in a test environment:

• ACL scope on first run: Check what filesystem paths the sandbox accounts are granted access to, specifically whether C:\Users\ and secondary drive roots are included.
• SSH key permissions: Verify that ~/.ssh/config and private key files are unmodified after Codex runs. OpenSSH's strict permission requirements make this a practical failure mode, not an edge case.
• Network policy defaults: Confirm that the offline identity is actually blocked from outbound traffic and that the approved-domain list matches your organization's expectations.
• Cleanup on uninstall: After removing Codex, check for stale ACL entries referencing CodexSandboxOffline or CodexSandboxOnline SIDs across user profile directories and any secondary drives.

The sandbox controls add real constraints that weren't there in March. For teams where local read access to developer machines is a hard constraint, the outstanding questions are worth answering before deployment, not after.