Home
AI
Blog

Codex Comes for Windows: a practical dev’s guide

basanta sapkota

Ever tried one of those “AI coding tools” that’s pretty decent… right up until it smacks into your actual Windows reality? PowerShell execution policies. WSL paths look fine until they don’t. Corporate permissions. And yes, that one repo with the cursed ACLs.

That’s why Codex comes for Windows is a bigger deal than “cool, a desktop app.” OpenAI shipped a Windows-native Codex app with a native agent sandbox and proper PowerShell support. So the agent can run where a lot of us actually live day-to-day. No forced VM detour.And mandatory “just use WSL.” It’s Windows. But with guardrails.

OpenAI also says the Windows version landed as a March 4, 2026 update to the Codex app announcement. Translation? Windows isn’t the “maybe later” platform anymore.

Key takeaways

Here’s the stuff you’ll actually care about when you go to install and use it.

Codex comes for Windows as a native desktop app, and it includes a Windows-native agent sandbox plus PowerShell support.

Install is straightforward. You can grab it from the Microsoft Store, or do the repeatable setup route with:

winget install Codex -s msstore

The sandbox is built to keep mistakes contained. Think restricted tokens/ACLs, plus network controls where the agent needs explicit approval before it talks to the outside world.

And you don’t have to break up with WSL. You can keep projects in WSL, open them from \\wsl$\..., or even switch the agent to run in WSL if fits your setup.

If the app faceplants on startup, it’s usually boring stuff. Permissions when trying to create %USERPROFILE%\.codex, or PowerShell execution policy problems.

What “Codex comes for Windows” actually means

When people say Codex comes for Windows, they’re talking about the official Codex app for Windows. It’s basically a desktop command center for agentic development.

Not vibes. Real, concrete features.

OpenAI describes the Codex app as a place where you can run multiple agents in parallel, keep them organized by project/thread, and review diffs without juggling a dozen windows.

On Windows, it runs natively using PowerShell and a Windows sandbox. If you’d rather, you can configure it to run with WSL instead.

Engadget calls out the same big ideas: multi-agent coordination, automations for repetitive work like bug testing, and a dedicated Skills section for reusable workflows.

If you’ve ever bounced between terminal tabs, IDE panes, and chat history trying to remember what the agent changed… yeah. The pitch is simple. Separate threads, isolated work, and reviews that feel less like archaeology.

Install Codex on Windows

OpenAI’s official guidance is Microsoft Store first, and updates come through the Store update mechanism too.

But if you’re like me and you want installs you can repeat without clicking around, the docs include a winget option:

winget install Codex -s msstore

Then you open Codex, sign in, add a project, and you’re off. In enterprise setups, admins can deploy it via Microsoft Store distribution tooling, according to OpenAI’s Windows app docs.

Quick checklist before first run

OpenAI recommends having the usual dev tools on the machine since the agent will call them as it works.

winget install --id Git.Git
winget install --id OpenJS.NodeJS.LTS
winget install --id Python.Python.3.14
winget install --id Microsoft.DotNet.SDK.10
winget install --id GitHub.cli

If you want GitHub features inside the app, you’ll also want:

gh auth login

The Windows-native sandbox: what it blocks, what you control

This is the part I care about most with Codex comes for Windows. Windows-native sandboxing, done on purpose, not as an afterthought.

OpenAI’s Windows Codex docs describe a sandbox approach that:

  • blocks filesystem writes outside the working folder
  • prevents network access unless you explicitly approve it
  • uses OS-level controls in elevated mode, including restricted tokens, filesystem ACLs, a dedicated sandbox user, and Windows Firewall rules

So the agent can run real commands. But it’s boxed in by default. Which is… honestly what you want, because agents are great until they’re confidently wrong at 200 WPM.

Granting sandbox read access when it can’t “see” something

Sometimes the agent just can’t read a directory, and it’ll fail in ways that feel obvious only after you’ve burned 20 minutes. OpenAI documents a command to allow read access for the current session:

/sandbox-add-read-dir C:\absolute\directory\path

I like this because it’s a decent compromise. You don’t have to nuke sandboxing just because your repo relies on a shared SDK folder somewhere else on disk.

PowerShell vs WSL: pick what matches your repo reality

OpenAI’s Windows app page is refreshingly practical here.

By default, the agent runs Windows-native in PowerShell.

You can still open projects live in WSL by browsing \\wsl$\....

But here’s the catch: if you stick with the Windows-native agent, OpenAI recommends keeping projects on the Windows filesystem and accessing them from WSL via /mnt/<drive>/... for reliability.

Want the agent to actually run inside WSL? You can switch the agent in Settings, then restart the app.

That’s it. No ceremony.

Sharing config between Windows and WSL

The Windows app uses:

  • %USERPROFILE%\.codex

But the Codex CLI in WSL defaults to ~/.codex. If you want shared history/config, OpenAI suggests setting CODEX_HOME inside WSL:

export CODEX_HOME=/mnt/c/Users/<windows-user>/.codex

This lines up with what people have been running into in the OpenAI community thread too. Failures happen when the app can’t create local storage under .codex, usually permissions, profile path weirdness, that kind of thing.

Skills, worktrees, and multi-agent flow

OpenAI frames the Codex app as a way to supervise multiple long-running agents, not just ask for one-off snippets. They also mention built-in support for worktrees, which matters when you’ve got multiple agents touching the same repo and you don’t want them tripping over each other.

How would I run it? I’d start small and a little paranoid.

Maybe something like:

  • One agent implements a small feature behind a flag.
  • Another agent adds tests and actually runs them.
  • A third agent reviews the diff and spits out a risk checklist.
  • Then I look at diffs, not vibes, and decide whether it gets merged or sent back.

I’ve done the “ship it because the output sounded confident” thing before. It’s not my favorite hobby.

If you want a related workflow idea, I wrote about catching issues with AI-driven review patterns here.
Internal link: [How i use AI React code review to catch bugs early]

Common mistakes when Codex comes for Windows

1) PowerShell execution policy blocks scripts

If you see something like npm.ps1 cannot be loaded because running scripts is disabled, OpenAI’s docs suggest:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned

Do yourself a favor before changing this on a work machine. Read Microsoft’s execution policy guide and follow your org’s rules. This is one of those “tiny command, big consequences” areas.

2) Git features feel “missing”

Some app features depend on Git being installed natively on Windows. The fix is simple:

winget install Git.Git

3) WSL path + Git detection weirdness

OpenAI calls out a specific snag. when you’re using the Windows-native agent.

Their workaround is also specific: keep the repo on the Windows drive, and access it from WSL via /mnt/<drive>/....

Not glamorous, but it’s predictable.

4) Startup fails creating %USERPROFILE%\.codex

The OpenAI Developer Community thread points to permission problems when Codex tries to create a local SQLite folder under .codex.

Two practical things to try:

  • Run Codex as Administrator once, just to confirm you’re dealing with permissions.
  • In a managed environment, check device policies or folder access controls.

I’ve seen this pattern before with developer tools. If the profile folder is locked down, everything breaks in strangely quiet ways.

Suggested visuals (if you add screenshots)

A screenshot idea:

  • Screenshot: Codex app “Projects / Threads” view
    Alt text: “Codex comes for Windows showing multiple agent threads organized by project with diff review panel”

And a diagram that would genuinely help readers:

  • Diagram: Windows-native agent sandbox flow, agent → sandbox user/token → filesystem/network gates
    Alt text: “Codex comes for Windows native agent sandbox diagram with restricted token, ACL-limited writes, and firewall-based network controls”

So… is it worth installing?

Codex comes for Windows feels like OpenAI finally meeting Windows developers where they are. The practical win is the combination: a Windows-native agent, sandboxing that reduces blast radius, and the option to pull WSL in when it makes sense instead of making it your whole personality.

If you try it, keep it simple at first. One repo. Install tools via winget. Run one agent thread end-to-end and watch how the sandbox + diff review loop behaves. If it gets weird, it’ll probably be permissions, execution policy, or WSL path quirks. And if you’re going to ask for help, include the exact error. The tiny details are always the whole story.

Sources

Post a Comment