Codex introduces Windows sandbox with firewall rules and write-restricted tokens

• OpenAIDevs' post says Codex on Windows needed a sandbox that keeps agent workflows useful without forcing either constant approval prompts or full machine access.
• According to reach_vb's breakdown, the final design combines local sandbox users, Windows Firewall rules, ACLs, write-restricted tokens, and DPAPI-encrypted credentials instead of relying on one ready-made Windows isolation primitive.
• TheRealAdamG's screenshot shows the core boundary clearly: spawned processes can keep access to the active workspace while other workspaces and the network can be blocked.
• dkundel's post adds that OpenAI built the Windows sandbox as a dedicated open-source component, not just a generic VM wrapper around Codex.

OpenAI linked the full engineering post from its launch tweet, and TheRealAdamG's diagram screenshot is the quickest way to see the permission model: one workspace allowed, another denied, network denied. reach_vb's summary also surfaced the concrete building blocks, including the two local sandbox accounts and the helper executables that set up and launch restricted command trees.

OpenAI's core design goal was to let Codex read broadly enough to understand a repo, write inside the workspace, run normal dev tools, and keep outbound network access constrained unless the user allows it, according to reach_vb's summary of the post.

The boundary in TheRealAdamG's screenshot is process-tree based. Codex itself sits outside the boundary, while spawned tools such as shells, Python, PowerShell, Git, and SSH run inside it with narrower access.

OpenAI says Windows did not offer a ready-made sandbox primitive for this workload shape, and reach_vb's thread lists the three candidates the team evaluated: AppContainer, Windows Sandbox, and Mandatory Integrity Control.

The reason those primitives fell short was the same tradeoff in different forms: Codex needed local checkout access, arbitrary developer tooling, and enforcement that follows the whole spawned process tree. The post framed that as the hard part of bringing a coding agent to Windows, which thsottiaux described as part of OpenAI's broader push to make agents work better on Windows.

The implementation pieces that reach_vb pulled out are unusually concrete:

• CodexSandboxOffline and CodexSandboxOnline local users
• Windows Firewall rules for outbound network control
• ACLs for read and write boundaries
• Write-restricted tokens
• DPAPI-encrypted sandbox credentials
• codex-windows-sandbox-setup.exe for elevated setup
• codex-command-runner.exe to spawn restricted child processes

That list matters because it shows OpenAI solved the problem with standard Windows security machinery stitched into a custom harness, not with a single container layer. dkundel's post says that harness is open source.

The Windows sandbox writeup landed alongside broader interest in Codex's security controls. In badlogicgames' screenshot, a terminal session hits a cyber_policy filter and gets pointed to OpenAI's Trusted Access for Cyber program, while pvncher separately notes that Codex security information is reachable through ChatGPT.