Windows Codex Desktop 26.707.9981.0 exits during startup without reporting a crash

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

• #33111

Powered by Codex Action

codex-desktop-3a71d1a4-51c6-4294-afa9-a68a0ad95663-37996-t0-i1-174530-0.log

Additional confirmation from a Windows 11 ARM64 install:

• Same affected desktop package: OpenAI.Codex_26.707.9981.0_arm64__2p2nqsd0c76g0
• The AppX UI process starts, then the bundled ARM64 worker app\\resources\\codex.exe starts about five seconds later.
• That worker exits cleanly with 0x00000000 after 9.83 seconds; Windows destroys the AppX container shortly afterward.
• No Application Error/Event ID 1000, Crashpad dump, out-of-memory event, or GPU fault is recorded.
• Re-registering the MSIX package did not change the behavior.

This demonstrates the regression is not x64-specific. The duplicate report is #33376; closing it in favor of this issue.

Issue title

Windows ARM64 Codex desktop app exits 7-12 seconds after launch after primary runtime manifest 404

Description

The standalone Codex desktop app briefly opens and then exits completely after approximately 7-12 seconds on Windows 11 ARM64. The Codex terminal CLI continues to work normally on the same machine.

The desktop log shows that the packaged app launches successfully, starts the app-server transport, completes the initialization handshake, initializes the bundled Codex CLI, and reaches window ready-to-show. WSL detection reports that WSL is not installed. Shortly afterward, the primary runtime update check fails with 404 Not Found.

The runtime configuration logged for the selected primary runtime includes windows-x86_64, but no windows-aarch64 platform entry. Because the installed desktop package is ARM64, this may indicate a Windows ARM64 runtime packaging or platform-selection problem. This is a suspected correlation, not a confirmed root cause: the log contains no explicit fatal exception or exit reason.

The process disappears completely rather than leaving a blank or unresponsive window. No matching Windows Application Error event is recorded.

Reproduction steps

1. On a Windows 11 ARM64 computer, install the Microsoft Store ARM64 package OpenAI.Codex 26.707.9981.0.
2. Authenticate with ChatGPT.
3. Launch the standalone Codex desktop app.
4. Wait approximately 7-12 seconds.
5. Observe that the window closes and the desktop process exits completely.
6. Launch Codex from Windows Terminal and observe that the CLI continues to work normally.

Expected behavior

The Codex desktop app should remain open and usable on Windows ARM64. A missing or unavailable optional primary runtime update should not cause the desktop process to exit without an error message.

Actual behavior

The main window appears briefly, then the entire Codex desktop process exits after approximately 7-12 seconds. There is no visible error dialog and no Windows Application Error event. The terminal CLI remains functional.

Environment

• OS: Windows 11 Core, build 26200
• Architecture: ARM64
• Codex desktop package: OpenAI.Codex 26.707.9981.0 ARM64
• Bundled app-server version reported by the desktop log: 0.144.2
• Separately installed Codex CLI: 0.144.4 aarch64-pc-windows-msvc
• Git: 2.55.0.windows.2
• Terminal: Windows Terminal
• Authentication: ChatGPT
• codex doctor: 17 ok, 1 idle, 1 note, 0 warnings, 0 failures
• MCP servers: none
• config.toml: loads successfully
• Windows sandbox: unelevated
• WSL: not installed; WSL execution disabled

Troubleshooting performed

• Reinstalled the Codex desktop app.
• Repaired and reset the app.
• Removed all MCP configuration.
• Tested with the unrelated workspace temporarily renamed; behavior was unchanged.
• Disabled WSL execution.
• Switched to the unelevated Windows sandbox.
• Removed a UTF-8 BOM that previously made config.toml invalid.
• Verified the corrected configuration with codex doctor.
• Confirmed that the terminal CLI works while the desktop app still exits.
• Checked Windows events; no matching Windows Application Error event was present.

Sanitized desktop log excerpt

The originally identified t1 log contains only Git-origin worker messages. The relevant startup events are in the same session's matching t0 companion log. Identifiers and unrelated fields have been omitted.

2026-07-15T16:39:51.148Z info  [AppServerConnection] Initializing app-server transport
2026-07-15T16:39:51.148Z info  [AppServerConnection] Starting app-server connection hostId=local transport=stdio
2026-07-15T16:39:53.093Z info  [AppServerConnection] Transport start success connectionId=1 hostId=local transport=stdio
2026-07-15T16:39:53.259Z info  [AppServerConnection] initialize_handshake_result durationMs=165 outcome=success transportKind=stdio
2026-07-15T16:39:53.259Z info  [AppServerConnection] Codex CLI initialized
2026-07-15T16:39:53.500Z info  [window-manager] window ready-to-show appearance=primary hostId=local startupElapsedMs=160
2026-07-15T16:39:54.981Z error [wsl] error retrieving eligible distro error="Windows Subsystem for Linux is not installed"
2026-07-15T16:39:55.555Z info  [electron-message-handler] Codex runtime config selected artifact=codex-primary-runtime
    latest platforms: linux-x86_64, macos-aarch64, macos-x86_64, windows-x86_64
    windows-aarch64 entry: absent
2026-07-15T16:39:55.683Z warning [install-primary-runtime] primary_runtime_update_poll_failed errorMessage="Failed to download primary runtime manifest (404 Not Found)."

The log ends without an explicit fatal exception, shutdown reason, or process-exit event.

Possible duplicate issues

• https://github.com/openai/codex/issues/16502 - very similar Windows symptom: desktop opens and closes after a few seconds, CLI works, WSL is absent, and no Windows crash event is recorded. That report is x64 and points toward sandbox/ACL behavior rather than an ARM64 runtime-manifest mismatch.
• https://github.com/openai/codex/issues/16269 - similar immediate-exit symptom on Windows, but the reporter correlated it with repository/untracked-file handling rather than ARM64 or runtime selection.
• https://github.com/openai/codex/issues/17491 - Windows ARM64 desktop support issue. It concerns x64 emulation, freezes, and lag; it does not report this silent startup exit or the missing windows-aarch64 runtime entry. It is closed.
• https://github.com/openai/codex/issues/15179 - Windows Store app flash-exit associated with sandbox ACL failures under WindowsApps. The current report uses the unelevated sandbox and the reviewed desktop excerpt does not show the reported ACL failure signature.

Additional note

I can provide a longer, manually reviewed and sanitized excerpt if maintainers need more context. I will not upload the complete unreviewed log because it may contain private account, conversation, or local-environment data.

Additional confirmation from my environment

Environment:

Windows 11 ARM running in Parallels Desktop on Apple Silicon
OpenAI.Codex 26.707.9981.0 ARM64
Same physical Mac also running the macOS Chatgpt Work (codex) desktop app successfully

Behavior:

Codex launches and displays the main UI ("What should we work on?")
After approximately 1-2 seconds, the entire process exits without an error dialog
Windows records AppX container creation/destruction only; no Application Error event or crash dump is generated
Launching ChatGPT.exe directly exits with 0xC06D007F

Troubleshooting performed:

Reinstalled Codex
Reset application state
Rebuilt %USERPROFILE%\.codex
Tested with a completely different OpenAI account
Removed all local projects and Git repositories from the machine
Tested with and without Windows sandbox (elevated and unelevated)
Disabled GPU
Removed Windows update KB5101650 (this resolved unrelated Teams/Outlook authentication issues but had no effect on Codex)

Control comparison:

The same ChatGPT account works correctly in the macOS Codex desktop application on the same physical computer.
ChatGPT Classic also works correctly in the Windows VM.
Browser access works normally.

This strongly suggests the issue is specific to the Windows ARM64 desktop application rather than my account, local projects, Git repositories, or the underlying Apple Silicon hardware.

I can reproduce the same silent startup exit on a newer integrated ChatGPT/Codex Windows build.

Environment

• App package: OpenAI.Codex_26.715.3651.0_x64__2p2nqsd0c76g0
• App version: 26.715.3651.0
• OS: Windows 10 Home x64, build 19045
• Codex CLI: 0.144.5
• Package manifest minimum OS: 10.0.19041.0

Behavior

The app window appears, initializes for roughly 10–15 seconds, and then all ChatGPT.exe processes disappear. This reproduces on every launch.

• No Application Error or WER crash event
• No crash dump
• No Defender, AppLocker, or Code Integrity block
• The activated main process ends with exit status 0x00000000
• The desktop log ends on normal request-routing entries, with no graceful shutdown marker and no fatal error

Diagnostics and mitigations tested

1. Removed the older Codex package, reset Roaming/AppX local state, and installed the current official Microsoft Store MSIX.
2. Verified the MSIX Authenticode signature and installed package status.
3. The original startup showed a primary-runtime download beginning and then the app exited. I downloaded the exact official archive manually:

• Bundle: 26.715.12143
• Size: 382,909,956 bytes
• SHA-256: b9f2234ec901bf58ec14279d5dfa7304622fd0aeda975eb472fa9b64760063ed

1. Extracted it to the runtime location expected by the app:

%USERPROFILE%\.cache\codex-runtimes\codex-primary-runtime

1. Subsequent launches recognize the runtime and no longer start a runtime download, but the app still exits.
2. Removed stale local and account-side remote-control environments. Logs then showed connectionCount=0 and hostId=local; the exit persisted.
3. Launched with --disable-gpu; the exit persisted.
4. Disabled the built-in browser and Browser Use with:

``toml
[features]
in_app_browser = false
browser_use = false
`
Logs confirmed available=false browserPane=false reason=browser-pane-disabled` and no IAB backend startup; the exit persisted.

1. Restored the browser feature settings after the test.
2. Windows version satisfies the package manifest minimum requirement.

Remaining log signal

A nonfatal-looking request sometimes returns:

fs/readFile: 系统找不到指定的路径。 (os error 3)

Initialization otherwise succeeds: the local app-server connects, account/config/model/thread reads complete, and the log ends without a fatal entry.

This looks like a clean application-initiated or window-lifecycle exit rather than a conventional native crash. I can provide targeted sanitized log excerpts if useful.