Codex App Keeps Crashing on Windows? Break the Launch Loop

If the Codex desktop app opens for roughly 20 to 30 seconds, silently exits, and immediately starts again while the Codex CLI still works, stop relaunching it. Preserve ~/.codex, record the app version and exit pattern, try one supported Repair, and use the CLI until OpenAI ships or documents a desktop fix. A current Windows 11 report reproduced the loop with a blank profile and after an app Reset, so repeated state deletion is not a reliable recovery.

This guide owns that narrow desktop launch-loop symptom. Use the separate Codex browser crash recovery guide when opening the built-in Browser triggers the crash. Use the Codex high-memory guide when memory grows before the app fails. A SUBST drive failure has its own physical-path workaround.

Match the Exact Failure First

The August 10 report that anchors this guide described this sequence:

1. The ChatGPT desktop app opened in Codex mode.

2. It stayed alive for about 22 to 30 seconds.

3. It exited without an error dialog or an Application Error event.

4. It relaunched and repeated the same cycle.

5. The Codex CLI continued to work on the same computer.

That combination matters. It separates a desktop-front-end failure from a general Codex outage, invalid account, broken repository, or failed CLI install.

Do not treat every Windows crash as the same bug. Other public reports have traced similar-looking launches to ARM64 native modules, runtime staging, illegal instructions, AppX state, browser GPU failures, and project paths. The visible loop is a starting point, not a root-cause verdict.

Contain the Loop Without Deleting State

End the relaunch cycle before collecting evidence. In Task Manager, find the repeatedly appearing ChatGPT or Codex process, confirm that no desktop task is still producing work, and end only that process. Do not run a broad process-kill command that could stop an unrelated ChatGPT window, terminal CLI task, browser session, or local development process.

Leave %USERPROFILE%\.codex in place. It may contain task history, configuration, authentication state, and logs. Do not upload the directory, auth.json, logs_2.sqlite, raw transcripts, screenshots with local paths, or crash archives to a public issue.

If you already renamed the directory for a controlled test, keep the original intact and restore it only after the looping desktop process is stopped. A fresh profile that also crashes is useful evidence, but repeatedly moving the directory does not repair an app-wide regression.

Record the Package and Windows Boundary

Open PowerShell outside Codex and collect only non-secret version and package fields:

$package = Get-AppxPackage -Name OpenAI.Codex
$package | Select-Object Name, Version, Status, PackageFullName

Get-ComputerInfo |
  Select-Object WindowsProductName, WindowsVersion, OsBuildNumber

Then check the same time window in Windows Event Viewer:

$since = (Get-Date).AddMinutes(-10)

Get-WinEvent -FilterHashtable @{
  LogName  = 'Application'
  StartTime = $since
  Id       = 1000, 1001, 1002
} -ErrorAction SilentlyContinue |
  Select-Object TimeCreated, Id, ProviderName, Message

Redact usernames, local paths, repository names, and report identifiers before sharing the output. An empty result is still evidence: it means Windows did not record one of those common crash or hang events during the window you checked.

Finally, confirm the CLI boundary without exposing credentials:

codex --version
codex login status

If both commands work, record that fact. Do not paste token files, environment variables, or the full contents of config.toml into a report.

Read the Result Before Choosing a Fix

Use the evidence to choose the next branch:

The app exits cleanly and the CLI works

This is the closest match to the current crash-loop report. The reporter observed no panic line, no Windows Application Error or WER event, and a repeatable 22 to 30 second process lifetime. Treat the desktop as unavailable, keep working through the CLI, and monitor the upstream issue.

Windows records a native fault

Preserve the event time, exception code, faulting module, architecture, and package version. Do not copy a workaround from a different fault code. For example, an ARM64 native-module failure and an x64 runtime-staging failure can produce similar launch symptoms while requiring different upstream fixes.

Windows records a hang

An Application Hang event means the process remained alive but stopped responding. Record CPU, memory, and whether one conversation or restored pane triggers it. Do not report a hang as a silent exit.

The CLI fails too

Stop using this launch-loop workflow. Check the exact CLI error, authentication status, network path, and OpenAI service status. A desktop-only workaround cannot repair a shared account or network failure.

Try One Supported Repair

First install any Codex or ChatGPT desktop update offered by the Microsoft Store. Record the version before and after the update so the result is reproducible.

If no update is available, use Windows Settings:

1. Open Settings > Apps > Installed apps.

2. Open Advanced options for ChatGPT or Codex.

3. Select Terminate if the loop is still running.

4. Select Repair once.

5. Restart Windows and test one clean launch.

Microsoft documents Repair as the first supported recovery option for an app that is not running correctly. Reset is a stronger step and can remove app data or sign-in state. The current crash-loop report already reproduced after Reset and with a blank .codex profile, so another Reset has weak expected value for this exact symptom.

Do not sideload an old package from an unverified mirror, disable browser or GPU security boundaries as a permanent fix, edit files under WindowsApps, or delete runtime folders repeatedly. Those changes can create a second failure and make the original evidence harder to interpret.

Keep Working Through the Codex CLI

When the CLI passes the earlier checks, open a normal terminal in the repository:

Set-Location C:\path\to\your\repository
git status --short
codex

Confirm the repository path before asking Codex to edit files. Keep the same sandbox, approval, and repository rules you would use in the desktop app. The Codex app vs CLI guide explains the surface differences; using the CLI is a continuity path, not proof that the desktop defect is fixed.

A successful recovery should meet all of these checks:

• the desktop stays open for at least five minutes;

• it can open a harmless local project without relaunching;

• no new matching Event 1000, 1001, or 1002 appears;

• the CLI remains healthy; and

• the original .codex state remains preserved.

If only the CLI works, continue there and report the desktop as still blocked.

Report a Reproducible Upstream Case

Include:

1. Codex or ChatGPT desktop package version;

2. Windows edition and build;

3. CPU architecture;

4. approximate seconds from launch to exit;

5. whether the app relaunches automatically;

6. whether Event 1000, 1001, or 1002 appears;

7. whether codex --version and codex login status work;

8. whether Repair, Reset, or a blank profile was tested once; and

9. the last non-secret log category before exit, if you can isolate it safely.

Do not claim that cua_node, remote control, one warning line, or a background update caused the crash unless a maintainer or controlled reproduction proves it. The August 10 report correlates onset with a runtime update, but a fresh runtime still crashed. That narrows the investigation without establishing one cause.

Reusable Diagnostic Prompt

Give a working Codex CLI session this bounded request:

Diagnose a Windows desktop launch loop without editing, deleting, resetting, reinstalling, or uploading anything. Report the non-secret Codex desktop package version, Windows build, CPU architecture, approximate process lifetime, whether Application events 1000, 1001, or 1002 occurred in the matching window, and whether the Codex CLI works. Classify the symptom as a silent exit, native crash, hang, or broader CLI failure. Redact usernames, paths, repository names, tokens, transcripts, and request IDs. Stop before any state change.

To monitor the upstream issue without pasting a GitHub token into a prompt, start with Aident Loadout:

Follow https://aident.ai/SETUP.md

Then ask:

Check Aident Loadout authentication and Vault status. Discover the current read-only GitHub issue-search Action, inspect its schema, and preflight lookups for openai/codex issues 37752, 33119, 27781, and 33381. If the lookups are valid and free, execute them and return only issue number, state, updated time, title, labels, and canonical URL. Do not comment, react, edit, close, or create anything.

Set up Aident Loadout and monitor the Codex crash loop.

Sources

• OpenAI Codex desktop app

• OpenAI Codex CLI

• Microsoft Support: Repair apps and programs in Windows

• OpenAI Codex issue 37752: desktop exits after about 25 seconds while CLI works

• OpenAI Codex issue 33119: Windows desktop exits during startup without a reported crash

• OpenAI Codex issue 27781: desktop exits after runtime staging changes

• OpenAI Codex issue 33381: ARM64 native-module crash loop

• OpenAI Developer Community: Codex desktop crashes on Windows ARM64

• Reddit: Codex Windows app keeps crashing

Refresh this guide when issue 37752 changes state, OpenAI identifies the affected desktop build or runtime, or the Microsoft Store publishes a verified fix.