Codex runs natively on Windows now, and as of June 2026 it does a lot more than edit files. The CLI hit v0.136.0 on June 1. The desktop app drives Windows desktop applications through computer use. There is even an alpha admin sandbox you can provision with a single command. All of it is real. A good chunk of it is also still rough. So this guide on Codex on Windows walks through the install paths that actually work, where PowerShell beats WSL and where it doesn't, what computer use can touch, and the live bugs you will hit, so you can route around them before they cost you an afternoon.
The two install paths
Two different things get called "Codex on Windows," and they install differently.
The CLI is the terminal agent. You install it through npm with the scoped package name:
npm install -g @openai/codex
That @openai/ prefix is load-bearing. Run npm i -g codex by mistake and you pull down an unrelated 2012 package that has nothing to do with OpenAI, and then you spend twenty minutes wondering why codex prints garbage. Node 22 or newer is the floor. If Node isn't on the box, grab it first, reopen PowerShell so the PATH refreshes, then install.
OpenAI also ships a one-liner that skips npm entirely:
powershell -ExecutionPolicy Bypass -c "irm https://chatgpt.com/codex/install.ps1 | iex"
Both land you in the same place: a codex binary on PATH. Run codex, pick "Sign in with ChatGPT," and your Plus, Pro, Business, or Enterprise plan covers usage.
The desktop app is the second thing, and it is separate software. You get it from the Microsoft Store, or from a terminal:
winget install Codex -s msstore
The app gives you worktrees, in-app Git, the in-app browser, artifact previews, plugins, skills, and parallel agent threads in a window instead of a terminal. Per OpenAI's Windows app docs, it leans on a few tools being present already: Git, Node.js, Python, the .NET SDK, and the GitHub CLI. None are strictly required to launch. But a project that needs dotnet build will stall if the SDK isn't there.
PowerShell or WSL
OpenAI's own Windows CLI guide now tells you to run native by default: "The native Windows sandbox offers the best performance and highest speeds while keeping the same security." That is a reversal from a year ago, when WSL was the only sane option and native Windows came with a warning label.
Run native if your project is native. PowerShell scripts, .NET, anything that touches Windows paths and Windows tooling belongs in the native sandbox, where Codex isn't shuffling files across a translation layer. The CLI talks to PowerShell directly through ConPTY, which is why Windows 10 needs to be at version 1809 or later and why Windows 11 is the recommendation. You need winget available too, since the sandbox setup pulls components through it.
Reach for WSL2 when your toolchain is Linux-native: bash build scripts, a Docker-heavy flow, anything that assumes a POSIX filesystem. Launch an elevated PowerShell, run wsl --install, then run the same Codex install script inside the Linux environment. One thing to know going in. WSL1 got dropped back in Codex 0.115, when the Linux sandbox moved to bubblewrap, so if you are on WSL1 for some legacy reason, Codex will not sandbox there. Upgrade to WSL2 or stay native.
For most Windows developers writing day-to-day app code, native PowerShell is now the faster and less fiddly choice. The exception is real, but it stays the exception.
The sandbox, and the elevated alpha
Codex on Windows confines what the agent can write and reach. You pick the enforcement mode in config.toml:
[windows]
sandbox = "elevated"
Elevated is what OpenAI recommends when it works. It stands up dedicated lower-privilege sandbox users, filesystem permission boundaries, firewall rules, and local policy changes, which adds up to a stronger box than the alternative. Setting it up the first time needs administrator approval, because creating those users and policies is an admin operation.
That setup is what v0.136.0 turned into an explicit, scriptable step. The release added an alpha provisioning path:
codex sandbox setup --elevated
Run that once as admin and it provisions the elevated sandbox plumbing ahead of time, instead of having Codex try to bootstrap it mid-session. It's useful on a shared or locked-down machine where you want the privileged work done deliberately rather than triggered by an agent run. It is alpha, though, and it behaves like alpha, which brings us to the part you need before you commit to elevated mode.
If you don't have admin rights, or elevated setup keeps failing, fall back:
[windows]
sandbox = "unelevated"
Unelevated runs commands under a restricted token derived from your current user and applies ACL-based filesystem boundaries. The isolation is weaker. But it needs no admin and it sidesteps a cluster of setup bugs. There is also windows.sandbox_private_desktop = false, which you only touch if the private desktop breaks compatibility with something you are running.
Computer use on Windows
This is the genuinely new capability, and the one I'd test first. OpenAI shipped computer use to Windows in late May, landing in the desktop app around the 26.527 build on May 29 and getting a broader rollout note on June 2. Codex can now operate Windows desktop applications by looking at the screen and acting on it, not only by editing files in a repo. The May 21 "Appshots" feature feeds this. You send an app window straight to Codex with a Command-key combination, so it has the visual context to work against.
Two limits worth stating plainly. Computer use on Windows is not available in the EEA, the UK, or Switzerland at launch, so if you are in one of those regions the feature simply won't be there. And it lives in the desktop app, not the bare CLI. If you installed only @openai/codex from npm and you are hunting for computer use, you are in the wrong surface. Install the Store app.
Known Windows gotchas
The biggest live one is apply_patch failing to update existing files. This is the function Codex uses to edit code, and on Windows it breaks in several distinct ways. In the desktop app, the generated apply_patch.bat wrapper can point at the packaged executable under C:\Program Files\WindowsApps\... and return "Access is denied" before any patch is applied (#13959, #13965). Under default sandbox permissions, patches get refused outright and only go through with elevated rights (#13574). Large patches can fail because the patch body is still transported over argv on Windows, which is both a reliability wall and a cost hit (#15003). Mapped and UNC-backed worktrees throw "Access is denied" even when icacls shows the file is writable (#12350). The practical workaround: keep your repo on a local drive, not a mapped network path, and if edits keep getting refused, that is your sandbox permission mode talking, not Codex losing the plot.
The second cluster is the in-app browser and Chrome integration. On recent app builds, the in-app browser and Chrome plugin die with "windows sandbox failed: spawn setup refresh" when the node_repl kernel exits on startup (#25357). The reported workaround is flipping the sandbox from elevated to unelevated, which lines up with a string of elevated-setup failures, including "spawn setup refresh" errors and OS error 740 (#24098, #25362, #23712). Here's the awkward bit: elevated is the recommended mode, and it is also the mode breaking browser features for a meaningful number of people right now. If your browser tooling stops working after an update, switch to unelevated, confirm it comes back, and decide which you need more this week.
A short triage list for when something refuses to work:
- Edits silently refused or returning exit code 1: check sandbox mode, try unelevated, move the repo off any mapped drive.
- In-app browser or Chrome plugin dead: switch
sandboxtounelevated, restart the app. - Elevated setup won't provision: rerun
codex sandbox setup --elevatedfrom an admin PowerShell, and if it still throws OS error 740, fall back to unelevated and file against the open issues.
And pin your version once you find a combination that works. With the CLI moving from 0.135.0 on May 28 to 0.136.0 on June 1, a stable afternoon can turn into a broken one after a routine npm update.
One portability note
Whatever you set up here, the skills you write for Codex aren't locked to it. Codex reads the same open Agent Skills standard as Claude Code, Cursor, and Gemini CLI, so a SKILL.md you author once (say, with Knack) runs in Codex on Windows without a rewrite.
Get the install right, pick your sandbox mode with the browser bugs in mind, and keep an eye on the version you're pinned to. Native Windows is the right default now. It is just a default with sharp edges, and the edges are documented above.