[ChatGPT Mac desktop] Reopening a running Codex task repeatedly crashes renderer and opens an empty new chat #44787

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

ChatGPT desktop app 26.903.71938, build 8576 (production), bundle identifier com.openai.codex. Version read from the installed application metadata during diagnosis.

What subscription do you have?

ChatGPT account authentication; subscription tier omitted from this public report.

What platform is your computer?

macOS 26.6.2 (25G83), Apple M1 Max, arm64, 32 GiB RAM.
Embedded renderer version recorded by Crashpad: 152.0.7977.83.

What issue are you seeing?

Selecting an existing, actively running local Codex task in the ChatGPT desktop app for Mac makes the interface become blurry and then switch to an empty new chat. Selecting the original task again repeats the failure.

Six renderer crash metadata records were found within approximately 14 minutes. The main app and local Codex worker remain alive, and the task continues executing in the background. The user consequently loses reliable access to the running task's interface.

This report concerns the ChatGPT application's renderer and recovery behaviour. No macOS operating-system crash was established.

What steps can reproduce the bug?

Observed repeatedly on the affected installation on 11 September 2026:

1. Leave an existing local Codex task running.
2. Select that task in the desktop sidebar.
3. The task view begins to load, the interface becomes blurry, and an empty new chat appears.
4. Select the original running task again.
5. The same failure recurs while the task continues working in the background.

This is an existing-state reproduction, not a clean-profile minimal reproduction. The repeated failure is confirmed for one task; a separate diagnostic Codex task remained usable. Other tasks were not systematically tested.

What is the expected behavior?

Opening an active task should display its current conversation and preserve navigation while the worker continues. If its display process fails, recovery should retain or safely restore access to the affected task instead of repeatedly opening an empty new chat.

Additional information

Crash metadata and process continuity

Six existing Crashpad sidecar files contained:

{"capture_kind":"crash","osarch":"arm64","ptype":"renderer","ver":"152.0.7977.83"}

These records and their filesystem modification times establish repeated renderer crash capture; they are not decoded native stack traces.

Read-only process inspection showed the main ChatGPT process and Codex worker had been running continuously since well before the observed crashes. A replacement renderer process started at the time of the last crash metadata record. An independent task-status read afterwards showed the original task active, its latest turn inProgress, error=null, and recent completed tool activity.

Final failure timeline

Times below are elapsed from selecting the task. They are derived from the app log and the crash sidecar's modification time; wall-clock timestamps and private identifiers have been removed.

Later entries repeatedly report:

[electron-message-handler] Received item/completed for unknown conversation
[electron-message-handler] Conversation state not found

The layout error's full message is:

[electron-message-handler] [desktop-notifications][global-error] ResizeObserver loop completed with undelivered notifications.

The broad pattern of task display, renderer restart and new-chat navigation repeats around the other crash records.

Interpretation and limits

• Strongly supported: repeated renderer crashes followed by UI restart on a new-chat route, while the original local task remains alive.
• Suspected: a defect triggered when displaying this conversation, potentially involving layout/rendering pressure.
• The ResizeObserver errors are correlated evidence, not proof of the native crash cause. No definitive out-of-memory diagnosis, native stack trace, or specific failing component was obtained. The blur is user-observed.
• No whole-app restart, cache reset, installation change or user-state deletion was performed during diagnosis because the local task was still working.
• This does not establish an update regression or a reliable workaround.

Related reports checked

• [macOS] Desktop input lag after repeated ResizeObserver errors #44730 reports input lag and repeated ResizeObserver errors on the same app version. This report adds recorded renderer crashes and recovery into an empty chat; a shared root cause is not established.
• [macOS][Desktop] Restored 224 MB PDF preview causes crash/relaunch loop and makes task inaccessible #42730 concerns a crash/relaunch loop when a large PDF preview is restored. Here the main app and worker survive, and no large-PDF trigger has been established.

The full diagnostic evidence has also been submitted privately through OpenAI Support and escalated to a support specialist.

This public report contains selected technical fields and relative timings. It excludes account/contact details, conversation contents, task/project names, local usernames/paths, and private thread/session/crash/request identifiers. No raw logs or screenshots are attached.