›_ Codex Issues
Codex Issues / #17491

Windows ARM64 running Codex App in Emulation

Resolved 💬 19 comments Opened Apr 11, 2026 by nos1609 Closed Jun 23, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

26.406.31014

What subscription do you have?

Plus

What platform is your computer?

Windows 11 26H1 Arm64 (Microsoft Surface Pro 11 ARM)

What issue are you seeing?

The Codex Windows application is distributed without native ARM64 support.

On an ARM64 Windows device, all Codex processes (Codex.exe) run as x64 binaries under emulation, while other applications (e.g. VS Code) run as native ARM64.

This is visible in Task Manager:

  • Code.exe → ARM64
  • Codex.exe → x64 (emulated)

This indicates that the Codex app is not compiled for ARM64 Windows and relies on x64 emulation.

In addition to architectural mismatch, this leads to real usability issues:

  • UI periodically freezes for a few seconds
  • noticeable input lag during interaction
  • occasional unresponsiveness under normal usage

These issues are not observed in native ARM64 applications on the same device, even vscode's version of Codex extension runs smoother.

Screenshot attached for reference.

<img width="1034" height="858" alt="Image" src="https://github.com/user-attachments/assets/50cc616b-37c7-4d67-9f86-10c9b8ee535c" />

What steps can reproduce the bug?

  1. Use an ARM64 Windows device (e.g. Surface Pro 11) or a Windows 11 ARM64 VM in Parallels
  2. Install Codex app from Microsoft Store
  3. Launch the application
  4. Use the app normally (navigation, input, interactions)
  5. Observe periodic UI freezes and lag
  6. Open Task Manager and confirm Codex.exe runs as x64

Result:

  • UI freezes and lag occur during normal usage
  • Codex runs under x64 emulation instead of ARM64

What is the expected behavior?

The application should provide a native ARM64 build for Windows, similar to macOS Apple Silicon support.

This is especially relevant given the distribution through the Microsoft Store, which supports multi-architecture packaging (similar in concept to macOS universal binaries).

Currently, the absence of an ARM64 build contradicts the expectations set by this distribution model.

Expected:

  • Codex.exe runs as ARM64
  • smooth and responsive UI without freezes
  • no reliance on x64 emulation

At minimum:

  • clear communication about ARM64 support status and roadmap

Additional information

The UI freezes strongly suggest that x64 emulation negatively impacts runtime performance.

Windows on ARM is actively promoted by Microsoft, and major developer tools (e.g. VS Code) already provide native ARM64 builds.

The Codex App is featured in the AI Hub of the Microsoft Store, including on Copilot+ PC devices.

However, it lacks native ARM64 support, which is a core characteristic of the Copilot+ PC ecosystem.

This creates a mismatch between platform positioning and actual application capabilities.

The lack of ARM64 support creates a platform inconsistency, especially since macOS ARM (Apple Silicon) is already supported natively.

This gives the impression that Windows ARM is treated as a lower-priority platform, despite real performance issues affecting users.

View original on GitHub ↗

19 Comments

github-actions[bot] contributor · 3 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #16865
  • #16374

Powered by Codex Action

angeliti999 · 2 months ago

Same issue here. Please release a Windows ARM64 version of Codex.

romeo5353535353-ui · 2 months ago

Same issue. Please release Windows ARM64 version of Codex

jaredlander · 2 months ago

I am running Codex on an ARM based Windows 11 laptop and am trying to use WSL2 mode. When launching, I get this error.

An error has occurred
Codex crashed with the following error:

(code=126, signal=null).
Most recent error: /usr/bin/bash: line 1: /mnt/c/Users/JaredLander/.codex/bin/wsl/codex: cannot execute binary file: Exec format error
/usr/bin/bash: line 1: /mnt/c/Users/<UserName>/.codex/bin/wsl/codex: Success
Some things to try:

Check your config.toml for invalid settings
Check your settings to disable running in WSL if you are seeing compatibility issues
Try downloading a different version of the extension
Click reload to restart the Codex extension, or visit our documentation for additional help.

jonas-tech-art · 2 months ago

I have exactly the same issue like @jaredlander

airtaxi · 2 months ago

I needed this myself, so I put together an unofficial Windows ARM64 repackaging project for the Codex app:

https://github.com/airtaxi/codex-app-windows-arm64

There is also a prebuilt release for 26.429.30905 here:

https://github.com/airtaxi/codex-app-windows-arm64/releases/tag/26.429.30905

Download dist.7z, extract it, and run Install.bat. The installer imports the local signing certificate and installs the repackaged ARM64 MSIX.

This is not affiliated with, endorsed by, or supported by OpenAI. It is just a community workaround, and it should be treated as unofficial. I plan to keep maintaining builds for each Codex App version until official Windows ARM64 support is available.

TheBeems · 2 months ago
I needed this myself, so I put together an unofficial Windows ARM64 repackaging project for the Codex app: https://github.com/airtaxi/codex-app-windows-arm64 There is also a prebuilt release for 26.429.30905 here: https://github.com/airtaxi/codex-app-windows-arm64/releases/tag/26.429.30905 Download dist.7z, extract it, and run Install.bat. The installer imports the local signing certificate and installs the repackaged ARM64 MSIX. This is not affiliated with, endorsed by, or supported by OpenAI. It is just a community workaround, and it should be treated as unofficial. I plan to keep maintaining builds for each Codex App version until official Windows ARM64 support is available.

Does this also repackage the codex binary for wsl2 in arm64? So it fixes: https://github.com/openai/codex/issues/13565 ?

airtaxi · 2 months ago
> I needed this myself, so I put together an unofficial Windows ARM64 repackaging project for the Codex app: > https://github.com/airtaxi/codex-app-windows-arm64 > There is also a prebuilt release for 26.429.30905 here: > https://github.com/airtaxi/codex-app-windows-arm64/releases/tag/26.429.30905 > Download dist.7z, extract it, and run Install.bat. The installer imports the local signing certificate and installs the repackaged ARM64 MSIX. > This is not affiliated with, endorsed by, or supported by OpenAI. It is just a community workaround, and it should be treated as unofficial. I plan to keep maintaining builds for each Codex App version until official Windows ARM64 support is available. Does this also repackage the codex binary for wsl2 in arm64? So it fixes: #13565 ?

I think so. The script replaces most binary to native one as possible. Including codex.exe which hosts app-server

TheBeems · 2 months ago
> Does this also repackage the codex binary for wsl2 in arm64? So it fixes: #13565 ? I think so. The script replaces most binary to native one as possible. Including codex.exe which hosts app-server

I tested it, and it did not work. But I changed your repackaging project to include the arm64 codex for wsl in https://github.com/airtaxi/codex-app-windows-arm64/pull/3

Now I can finally use the codex app with native arm64 support and with wsl2! Thank you so much for making the repackaging project!

airtaxi · 2 months ago
> > Does this also repackage the codex binary for wsl2 in arm64? So it fixes: #13565 ? > > > I think so. The script replaces most binary to native one as possible. Including codex.exe which hosts app-server I tested it, and it did not work. But I changed your repackaging project to include the arm64 codex for wsl in airtaxi/codex-app-windows-arm64#3 Now I can finally use the codex app with native arm64 support and with wsl2! Thank you so much for making the repackaging project!

Thank you so much, @TheBeems. I really appreciate your contribution.

There has not been a new upstream Codex version since the last release, but I published a new post release with your changes here:

https://github.com/airtaxi/codex-app-windows-arm64/releases/tag/26.506.3741-post1

nos1609 · 2 months ago

Adding fresh power-efficiency data from the current official Microsoft Store build.

Environment:

  • Device: Microsoft Surface Pro with 5G, 11th Edition, Windows 11 ARM64
  • Codex Store package: OpenAI.Codex_26.506.3741.0_x64__2p2nqsd0c76g0
  • Package architecture: X64
  • Codex.exe PE machine: 0x8664 (AMD64/x64)
  • Battery: SurfaceBattery, full charge capacity about 45.46 Wh
  • Battery charge limit is enabled, so the practical 80% working capacity is about 36.37 Wh

Current battery-side observation:

  • PowerOnline = False, Discharging = True
  • 60-second WMI sample while using Codex interactively:
  • average discharge rate: about 8.36 W
  • min/max during the sample: 6.87 W / 10.15 W
  • remaining capacity at the end of the sample: about 34.54 Wh
  • estimated runtime at that average: about 4.13 h
  • A subsequent instant sample showed 15.13 W discharge and Windows reported 138 min estimated runtime.

Process CPU delta over a 15-second sample showed Codex as the dominant CPU consumer:

Process                  CpuSeconds/15s   Avg one-core %
Codex                    8.66             57.7%
Codex                    7.20             48.0%
Codex                    4.20             28.0%
LogiPluginService        3.58             23.9%
System                   2.73             18.2%
dwm                      2.08             13.9%
firefox                  1.59             10.6%
audiodg                  1.39              9.3%
Spotify                  0.84              5.6%

So the top three Codex processes alone consumed about 20 CPU-seconds over a 15-second wall-clock interval, i.e. roughly 1.3 logical cores sustained during the sample.

Network context for that sample:

  • Default route was Wi-Fi, not cellular.
  • Wi-Fi delta over 60 seconds: about 0.94 MB RX / 0.53 MB TX.
  • Cellular modem was connected, but traffic delta was 0 MB during the same sample.

This makes the issue broader than UI smoothness. On Windows ARM64/Copilot+ PC hardware, the x64-only Codex package also has a measurable battery/runtime cost. With an 80% battery charge limit, every sustained watt matters: moving from about 8.4 W to 6.5 W would be the difference between roughly 4.3 h and 5.6 h from an 80% charge on this battery.

The diagnostic collection itself may inflate the absolute discharge number a bit, but the process-level CPU delta still shows that the x64 Codex app processes are a major contributor during active use.

This is another reason to ship an official native Windows ARM64 package instead of relying on x64 emulation or community repackaging.

dakehero · 2 months ago

@airtaxi Does this package also include an Win arm64 version of codex-windows-sandbox？

airtaxi · 2 months ago
@airtaxi Does this package also include an Win arm64 version of codex-windows-sandbox？

Yes it pulls windows aacrh64 version of codex-windows-sandbox and replace existing x64 version of it while repackaging process.
If sandbox doesn't work as intended, please let me know

dakehero · 2 months ago

@airtaxi I notice that there are 3-4 binaries have x64 fallback, could we build these binaries from upstream source instead of using the x64 fallback?

airtaxi · 2 months ago
@airtaxi I notice that there are 3-4 binaries have x64 fallback, could we build these binaries from upstream source instead of using the x64 fallback?

Thanks for the feedback.

For the remaining x64 fallbacks, here is the current status from my side:

  • node_repl.exe: this appears to be a binary produced by OpenAI, but I could not find its corresponding source, so I was not able to consider it as a rebuild target.
  • tectonic.exe: the source is available, but official ARM support appears to cover only macOS and Linux. I did consider downloading the source and attempting a Windows ARM64 cross-compile, but since it is only used by the LaTeX submodule, the added build complexity felt disproportionate. I left it as an x64 fallback, since running it through emulation should be acceptable for that use case.
  • extension-host.exe: this seems to be a recently added binary related to the Codex Chrome extension support. I could not find its source or an official ARM64 binary distribution. If you or anyone knows where this is built or distributed from, please let me know in this issue.

Also, while reviewing the x64 fallback list, I noticed that some binaries which are already available as ARM64 were still included in the fallback allowlist unnecessarily. I recently patched that so those binaries are no longer allowed to remain as x64 fallbacks.

In other words, the current fallback list is intended to contain only the binaries that I could not reasonably replace with native Windows ARM64 builds at this point.

dakehero · 2 months ago
> @airtaxi I notice that there are 3-4 binaries have x64 fallback, could we build these binaries from upstream source instead of using the x64 fallback? Thanks for the feedback. For the remaining x64 fallbacks, here is the current status from my side: node_repl.exe: this appears to be a binary produced by OpenAI, but I could not find its corresponding source, so I was not able to consider it as a rebuild target. tectonic.exe: the source is available, but official ARM support appears to cover only macOS and Linux. I did consider downloading the source and attempting a Windows ARM64 cross-compile, but since it is only used by the LaTeX submodule, the added build complexity felt disproportionate. I left it as an x64 fallback, since running it through emulation should be acceptable for that use case. * extension-host.exe: this seems to be a recently added binary related to the Codex Chrome extension support. I could not find its source or an official ARM64 binary distribution. If you or anyone knows where this is built or distributed from, please let me know in this issue. Also, while reviewing the x64 fallback list, I noticed that some binaries which are already available as ARM64 were still included in the fallback allowlist unnecessarily. I recently patched that so those binaries are no longer allowed to remain as x64 fallbacks. In other words, the current fallback list is intended to contain only the binaries that I could not reasonably replace with native Windows ARM64 builds at this point.

@airtaxi Thanks
I’ve confirmed that tectonic is buildable on Windows ARM64. I’ll try to send an upstream PR to update the CI/release workflow to support publishing win-arm64 release artifacts.

jaredlander · 1 month ago

I tried updating the Codex app using winget and it says there are no new updates. So I am guessing this has not been solved yet.

junhaoliao · 27 days ago

Seems like the Codex app has finally released arm64 binaries. Maybe this issue can be closed now?

<img width="1095" height="333" alt="Image" src="https://github.com/user-attachments/assets/5bf72e08-1be7-441a-b1c5-d9a823cd4dde" />

nos1609 · 27 days ago

Finally great news, native ARM64 binaries across the whole codex app in v26.521.10419, even node_repl is not x64 anymore.

Now I'm at least not draining my battery for emulation.
Thanks OpenAI