OpenAI Codex App for Windows: A Build-It-Yourself Tutorial (With Installer)
Feb 04, 2026
OpenAI has a habit of releasing macOS-only products first. Fortunately, this time around, Codex is built with Electron (a framework that lets developers build desktop apps using web technologies) for its UI, while relying on Codex CLI under the hood. That opens up the possibility of reverse-engineering and rebuilding a Windows version.
Pre-Built Installer
This is just for trying it out — a proof of concept, not a maintained release.
-
Download here: https://github.com/Loongphy/codext/releases/tag/rust-v0.94.0
-
Alternatively, check out CodexDesktop-Rebuild, which inspired this article. Note that it uses a modified version of Codex CLI, though I’m not sure what they changed.
I still mainly use Codex CLI directly — the app is rarely my go-to. After all, the UI is just a wrapper around Codex CLI, and I’m perfectly happy with my current workflow; I don’t need a GUI. I also can’t give up WSL2 (Windows Subsystem for Linux — a feature that lets you run a real Linux environment directly inside Windows). The Windows app can only access WSL files through cross-filesystem paths like \\wsl.localhost\Debian\root, which makes file operations painfully slow.
Feel free to drop questions in the comments. Before the official release, I’ll keep updating alongside Codex CLI releases.
As the saying goes — teach a man to fish. I hope that after reading this article, you’ll be able to build and fix things on your own 🫡.
Downloading the macOS Installer
You’ll need to trick Chrome into pretending it’s running on macOS — by spoofing the User Agent (the string your browser sends to websites to identify itself) and Client Hints (a modern mechanism browsers use to share device info). Then open https://openai.com/codex/ to download the codex.dmg installer (.dmg is the standard macOS installer format):
- Open DevTools: press
F12orCtrl+Shift+I - Open the command menu:
Ctrl+Shift+P, type Network conditions, and select Show Network conditions (a panel will appear at the bottom of DevTools). - In the User agent section, uncheck Use browser default, then:
- Select a macOS / Safari option from the dropdown (if available)
- (This is crucial) Expand the User agent client hints dropdown and change the
platformfield to macOS, then click Update. Many websites nowadays rely more heavily on Client Hints than the traditional UA string, so this step is what actually makes the spoofing work. - Refresh the page.
Building the Codex Windows App
I much prefer developing inside WSL2 with CLI-based agents. The Windows terminal experience is an absolute nightmare — LLMs tend to make more mistakes there too, and accidental file deletions are all too common.
Create an empty folder, copy the downloaded .dmg file into it, open this directory in WSL2, run codex, type /Approvals to grant Full Access permissions, and let’s go!
- Initial Prompt
Based on the current state of my repository, help me repackage a "macOS-packaged Electron application" into a version that can be built and packaged on Windows.
## Project Goal
- I only have a macOS installer (a post-build Electron .dmg). I want to rebuild it into a working Windows app.
- I'm not trying to recover source code or recompile the frontend. The goal is "repackaging": take the already-packaged output as input and rebuild it into a runnable Windows app.
- The backend CLI is provided by the Codex CLI process: on Windows we need `codex.exe`, obtained via the `@openai/codex` package which provides pre-compiled binaries for each platform.
## Deliverable
- A Windows installer
## Notes
- We're in a WSL2 environment. For Windows-specific dependency packaging, you'll need to invoke `pwsh.exe`.
Being an Observer
AI users tend to let the tool fix every error for them, rarely thinking independently. Over time, this weakens their ability to spot and fix bugs on their own — which is precisely the skill you need most when supervising AI output.
I’ve seen plenty of people doing Vibe Coding (writing code by feel, leaning heavily on AI) who only look at the final result and blame the agent, without ever examining the process to see where things went off track.
Here are a few issues I observed while watching Codex CLI work:
prefer uv not python
During execution, I noticed it was using Python. Since I didn’t want it leaving junk all over my system by installing random dependencies, I added a prefer uv not python instruction mid-run.
That said, it still went ahead and installed Python directly rather than using uv, so I’d recommend putting this kind of requirement in your initial prompt or your AGENTS.md file (a configuration file that Codex CLI treats as its highest-priority instruction set).
Codex CLI treats instructions in AGENTS.md as top priority and follows them strictly — it rarely overlooks them.

- Install Visual Studio Community
The packaging process uses Visual Studio Tools, so you may need to install Visual Studio Community first. You’ll need the same setup as Electron development requires: install the Desktop development with C++ workload.

The Result: One Run
With just the initial prompt and one mid-run instruction (prefer uv not python), the whole thing finished in 41 minutes.

It did run successfully, though there were still a few bugs — the window wasn’t properly resizable, and selecting a project triggered an Oops, an error has occurred message.
All of these were fixed with a single follow-up prompt. Now, let’s play with it!
All hail Codex CLI!
An Alternative Build Path
Maybe you don’t want to build locally or deal with installing a bunch of dependencies. You can try running Codex CLI inside GitHub Actions (GitHub’s built-in automation platform) — set it up to build in a Windows environment using codex "your instructions", then upload the packaged output as an Artifact so you can download it directly.
You might need to tweak the prompt to make it keep retrying until the build succeeds, since Codex CLI tends to ask questions rather than just powering through autonomously.

Looking Ahead
Building a proper Windows version isn’t that simple. I don’t expect them to use WinUI 3 — even Microsoft itself is stuck in a technical quagmire on that front. But I do hope that every developer building programming tools will give some thought to WSL2 compatibility and deliver a native Linux development experience on par with what VS Code offers.