[Windows App][Crash] read_thread on a ChatGPT conversation reference closes the app

Open 💬 2 comments Opened Aug 24, 2026 by 34925

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

26.818.5229.0 (package OpenAI.Codex_26.818.5229.0_x64__2p2nqsd0c76g0)

What subscription do you have?

ChatGPT subscription (exact tier not available in the reporting context)

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

On Windows, the desktop app terminates after Codex tries to inspect a referenced ChatGPT conversation whose cached priorConversation preview is null.

The referenced item is correctly identified as kind: "chatgpt" by list_threads, but read_thread sends its ChatGPT conversation ID to the local Codex app-server method thread/read. The app server returns -32600 thread not loaded. That error is followed by an Electron main-process crash instead of being returned as a recoverable tool error. A manual restart is required.

Controlled reproduction (app-log timestamps are UTC; 09:04 JST):

2026-08-24T00:04:23.835Z dynamic_app_tool_server_request_received tool=read_thread
2026-08-24T00:04:23.854Z dynamic_app_tool_thread_read_started tool=read_thread
2026-08-24T00:04:23.920Z method=thread/read errorCode=-32600
2026-08-24T00:04:23.921Z Request failed: thread not loaded

Crashpad created a report 10.5 seconds later:

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

In Chromium/Electron terminology, ptype: "browser" identifies the Electron main process. From 2026-08-20 19:51 JST through 2026-08-24 09:04 JST, 19 app sessions ended with the same thread not loaded → Crashpad main-process crash sequence. Seventeen incidents involved one ChatGPT conversation and two involved another, so this is not specific to one conversation's content.

ChatGPT conversation IDs and conversation contents are intentionally omitted.

What steps can reproduce the bug?

  1. In a Codex task, reference an existing ChatGPT conversation.
  2. Ensure the generated reference payload has priorConversation: null.
  3. Ask Codex to inspect the referenced conversation.
  4. Codex invokes read_thread with the redacted ChatGPT conversationId and turnLimit: 10.
  5. The dynamic tool handler invokes local app-server thread/read.
  6. The app server returns -32600 thread not loaded.
  7. About 8–23 seconds later, the desktop app closes and must be restarted manually.

This was reproduced directly on 2026-08-24 at 09:04 JST.

What is the expected behavior?

read_thread should retrieve the referenced ChatGPT conversation. If that source cannot be read, it should return a non-fatal tool error explaining the failure. The Electron main process and desktop app must remain running.

Additional information

Routing evidence from list_threads (identifiers omitted):

{
  "kind": "chatgpt",
  "status": "idle",
  "hostId": null
}

Codex threads include hostId: "local", but ChatGPT conversations do not expose a host/source value that callers can pass to read_thread. The likely defect is that the desktop dynamic-app-tool implementation does not preserve or resolve the backing kind before dispatching read_thread; a ChatGPT ID is routed to local thread/read, and the resulting rejection is not safely contained.

Suggested fix:

  1. Preserve the backing kind/source from the ChatGPT conversation reference.
  2. Route kind: "chatgpt" IDs to the ChatGPT conversation reader rather than local thread/read.
  3. Catch -32600, timeouts, and source-resolution failures at the dynamic tool boundary and return a normal tool error.
  4. Add a Windows regression test for a referenced ChatGPT conversation with priorConversation: null.
  5. Add a regression test proving an unknown ID returns a recoverable error and leaves the app running.

Additional environment checks:

  • Installed executable signature is valid and signed by OpenAI OpCo, LLC.
  • Microsoft Store updater returned NoUpdates at 2026-08-24 09:05 JST.
  • No raw logs are attached because session transcripts may contain sensitive content.

Temporary workaround: avoid chatgpt-conversation://... references with a null preview; paste the needed turns or attach a sanitized export.

View original on GitHub ↗

2 Comments

MilkyWay008 · 4 days ago

Same thread not loaded (-32600) crash path here on Win11 with the Codex app. Your workaround is solid for now: the chatgpt-conversation:// refs with null preview are what nuke the reader thread, so pasting the turns instead of referencing them keeps sessions alive. If you grab the Crashpad dump before it dies (%LOCALAPPDATA%\CrashDumps) and relaunch with --enable-logging, that usually makes the trigger obvious for the team. Oh btw, I built a portable Hermes OTG for exactly these 'app dies and you're stuck' moments, imo it's handy for diagnosing from a working agent, https://github.com/MilkyWay008/Hermes-OTG

34925 · 4 days ago

Thanks for confirming that you can reproduce the same crash.

The most useful additional information would be:

  • Codex app version
  • Windows version/build
  • Whether the reference had priorConversation: null
  • Sanitized timestamps showing the -32600 thread not loaded error followed by the app crash

Please omit conversation IDs and conversation contents.

In my environment, %LOCALAPPDATA%\CrashDumps exists, but it does not contain a dump for ChatGPT.exe or Codex. The Crashpad evidence in this issue came from the Codex app logs and crash metadata, so I do not want to assume that the Windows Error Reporting dump path applies here.

--enable-logging may provide additional Chromium/Electron logs, but I will avoid collecting or uploading raw logs unless an OpenAI maintainer requests specific artifacts, because they may contain sensitive session information.

For now, pasting the required turns or using a sanitized export remains the safest workaround.

Disclosure: Codex is assisting with the investigation, local evidence collection, drafting, and posting of this issue and its follow-up comments. I review the results and explicitly approve each external submission.