Windows desktop app repeatedly crashes in browser process, especially in Local Work mode

Open 💬 2 comments Opened Aug 25, 2026 by heirloomsco
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Description

The ChatGPT/Codex Windows desktop app repeatedly crashes and completely exits, most frequently while using Local Work mode. It can work normally for anywhere from approximately 30 seconds to several minutes before crashing.

Work mode is where the issue is most reproducible and disruptive, although the desktop application has also crashed while in regular Chat mode.

Feedback session ID

no-active-thread-01a03abd-3f53-7af0-b649-7ef242324d34

Environment

  • WindowsProductName: Windows 10 Pro
  • WindowsVersion: 2009
  • OS Build: 26200
  • Architecture: 64-bit
  • OpenAI.Codex version observed after reinstall: 26.818.2872.0
  • Logs have referenced browser runtime release 26.818.22352

Crash information

Crashpad sidecar JSON consistently reports:

{"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}

Earlier crashes generated Crashpad .dmp files approximately 43 MB in size. Those dump files are no longer retained locally, although the Crashpad sidecar JSON files remain.

The desktop logs show the application and Codex CLI initializing successfully and the local connection reaching the connected state. Around the crashes, the logs have also reported browser main-thread jank before terminating without a normal/graceful shutdown.

No %USERPROFILE%\.codex\.sandbox\sandbox.log is present.

Troubleshooting already performed

I have already tried:

  • Windows app reset
  • Complete uninstall and reinstall of the desktop application
  • Creating a completely fresh .codex environment by renaming the existing .codex directory
  • Testing Work before restoring the previous local sessions
  • Restoring only sessions, archived_sessions, and session_index.jsonl afterward
  • Testing different GPU assignments/settings
  • Disabling concurrent_reasoning_summaries
  • Checking Windows Code Integrity logs

The crash continued with a completely fresh .codex state, so it does not appear to be caused by my existing Work conversations/session data.

Windows Code Integrity does contain Event 3033 entries involving Chrome and vk_swiftshader.dll, but a targeted search found no corresponding Code Integrity events involving ChatGPT.exe or OpenAI.Codex.

Reproduction

  1. Launch the Windows desktop app.
  2. Enter/use Local Work mode.
  3. Begin using a Work conversation normally.
  4. The app works initially.
  5. After approximately 30 seconds to several minutes, the entire desktop application can abruptly exit.
  6. Crashpad records the event as ptype: "browser".

The issue is not strictly limited to Work because I have also experienced desktop crashes in regular Chat mode, but Local Work is where it happens most consistently.

WSL isolation test

OpenAI Support suggested switching the agent environment from Windows native to WSL under Settings. My current desktop build does not show an "Agent environment" setting, so I was unable to perform this test.

Impact

This makes Local Work effectively unusable for me. I specifically rely on the Windows Work environment for local file/app access and computer/browser functionality.

I can provide additional log excerpts, Crashpad sidecar data, or reproduce the issue again if engineering needs a specific diagnostic captured immediately after a crash.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 2 days ago

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

  • #40576
  • #40349

Powered by Codex Action

heirloomsco · 2 days ago

The duplicate detector surfaced #40349 and #40576.

#40349 appears particularly relevant because its Crashpad metadata exactly matches what I am seeing:

capture_kind=crash
ptype=browser
osarch=x86_64

I am also experiencing the entire Windows desktop application terminating without a useful Windows Application Error/WER event.

My reproduction differs somewhat because the crashes occur primarily during Local Work use and are not limited to reopening an oversized/browser-heavy task. I have also experienced crashes outside Work.

I am leaving this issue open for now because I am not certain whether the underlying trigger is identical, but #40349 appears potentially related to the same Windows Electron browser/main-process failure.