Use Codex on Windows with the native ChatGPT desktop app, the CLI, or the IDE extension.
The ChatGPT desktop app on Windows supports core workflows such as parallel tasks, worktrees, scheduled tasks, Git functionality, the built-in browser, file previews, plugins, and skills.
The app can run natively in PowerShell with a Windows sandbox instead of requiring WSL or a virtual machine. This keeps Codex in Windows-native workflows while enforcing bounded filesystem and network permissions.
The native Windows sandbox has two modes:
- natively on Windows with the stronger
elevatedsandbox, - natively on Windows with the fallback
unelevatedsandbox.
Configure the Windows sandbox
When you run Codex natively on Windows, agent mode uses a Windows sandbox to block filesystem writes outside the working folder and prevent network access without your explicit approval.
Native Windows sandbox support includes two modes that you can configure in
config.toml:
[windows]
sandbox = "elevated" # or "unelevated"elevated is the preferred native Windows sandbox. It uses dedicated
lower-privilege sandbox users, filesystem permission boundaries, firewall
rules, and local policy changes needed for commands that run in the sandbox.
unelevated is the fallback native Windows sandbox. It runs commands with a
restricted Windows token derived from your current user, applies ACL-based
filesystem boundaries, and uses environment-level offline controls instead of
the dedicated offline-user firewall rule. It’s weaker than elevated, but it
is still useful when administrator-approved setup is blocked by local or
enterprise policy.
If both modes are available, use elevated. If the default native sandbox
doesn’t work in your environment, use unelevated as a fallback while you
troubleshoot the setup.
Enterprise administrators can constrain which native sandbox implementations
Codex can use through requirements.toml:
[windows]
allowed_sandbox_implementations = ["elevated"]This example requires the elevated sandbox and prevents users from falling
back to unelevated. To permit either implementation, include both values;
Codex prefers elevated when no mode is selected. See the
requirements.toml reference for
the supported values.
By default, both sandbox modes also use a private desktop for stronger UI
isolation. Set windows.sandbox_private_desktop = false only if you need the
older Winsta0\\Default behavior for compatibility.
Sandbox permissions
Running Codex in full access mode means Codex is not limited to your project directory and might perform unintentional destructive actions that can lead to data loss. For safer automation, keep sandbox boundaries in place and use rules for specific exceptions, or set your approval policy to never to have Codex attempt to solve problems without asking for escalated permissions, based on your approval and security setup.
Windows version matrix
| Windows version | Support level | Notes |
|---|---|---|
| Windows 11 | Recommended | Best baseline for Codex on Windows. Use this if you are standardizing an enterprise deployment. |
| Recent, fully updated Windows 10 | Best effort | Can work, but is less reliable than Windows 11. For Windows 10, Codex depends on modern console support, including ConPTY. In practice, Windows 10 version 1809 or newer is required. |
| Older Windows 10 builds | Not recommended | More likely to miss required console components such as ConPTY and more likely to fail in enterprise setups. |
Additional environment assumptions:
wingetshould be available. If it’s missing, update Windows or install the Windows Package Manager before setting up Codex.- The recommended native sandbox depends on administrator-approved setup.
- Some enterprise-managed devices block the required setup steps even when the OS version itself is acceptable.
Grant sandbox read access
When a command fails because the Windows sandbox can’t read a directory, use:
/sandbox-add-read-dir C:\absolute\directory\pathThe path must be an existing absolute directory. After the command succeeds, later commands that run in the sandbox can read that directory during the current session.
Use the native Windows sandbox by default. Choose WSL when you need Linux-native tooling, your workflow already lives in WSL2, or neither native Windows sandbox mode meets your needs.
Troubleshooting and FAQ
If you are troubleshooting a managed Windows machine, start with the native sandbox mode, Windows version, and any policy error shown by Codex. Most native Windows support issues come from sandbox setup, logon rights, or filesystem permissions rather than from the editor itself.