Skip to content

Windows ARM64 running Codex App in Emulation #17491

Closed

Description

@nos1609

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.

Image

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.

Activity

  1. added
    appIssues related to the Codex desktop app
    on Apr 11, 2026
  2. github-actions commented on Apr 11, 2026

    @github-actions
    Contributor
  3. angeliti999 commented on Apr 23, 2026

    @angeliti999

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

  4. romeo5353535353-ui commented on Apr 30, 2026

    @romeo5353535353-ui

    Same issue. Please release Windows ARM64 version of Codex

  5. jaredlander commented on May 2, 2026

    @jaredlander

    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//.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.

  6. jonas-tech-art commented on May 4, 2026

    @jonas-tech-art

    I have exactly the same issue like @jaredlander

  7. airtaxi commented on May 4, 2026

    @airtaxi

    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.

  8. TheBeems commented on May 9, 2026

    @TheBeems

    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 ?

  9. airtaxi commented on May 10, 2026

    @airtaxi

    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

  10. TheBeems commented on May 10, 2026

    @TheBeems

    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!

  11. airtaxi commented on May 11, 2026

    @airtaxi

    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

  12. nos1609 commented on May 15, 2026

    @nos1609
    Author

    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.

  13. dakehero commented on May 17, 2026

    @dakehero

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

  14. airtaxi commented on May 17, 2026

    @airtaxi

    @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

  15. dakehero commented on May 18, 2026

    @dakehero

    @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?

  16. airtaxi commented on May 18, 2026

    @airtaxi

    @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.

  17. dakehero commented on May 18, 2026

    @dakehero

    @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.

  18. jaredlander commented on Jun 4, 2026

    @jaredlander

    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.

  19. junhaoliao commented on Jun 23, 2026

    @junhaoliao

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

    Image
  20. nos1609 commented on Jun 23, 2026

    @nos1609
    Author

    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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appenhancementNew feature or requestwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions