Repository navigation
[Windows 26.901.6511.0] Repeated renderer crashes and UI recovery while the main process stays alive #43557
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.901.6511.0 (installed Windows package: OpenAI.Codex; executable: ChatGPT.exe)
What subscription do you have?
ChatGPT Pro
What platform is your computer?
Windows 11 Pro for Workstations, build 26200, x64
What issue are you seeing?
The desktop interface repeatedly disappears/reloads and then returns during an active task. This interrupts the user experience and looks like the app is closing and reopening. Local diagnostics confirm renderer crashes; the main application process remained alive.
Six Crashpad sidecar files were recorded on 2026-09-07 at the following local times (UTC+05:00):
- 22:47:47
- 23:25:33
- 23:33:00
- 23:34:10
- 23:36:37
- 23:41:02
Each of these six sidecars contains:
{"capture_kind":"crash","osarch":"x86_64","ptype":"renderer"}The main ChatGPT.exe process had been running continuously since 19:17:35. The last Crashpad sidecar was written at 23:41:02.256; a new renderer process was created at 23:41:02.778. This is consistent with renderer recovery after a crash rather than a full main-process restart.
The current-day desktop text log files were empty when checked. The retained sidecar metadata does not contain an exception code or stack trace, so the underlying cause has not been identified.
What steps can reproduce the bug?
No minimal deterministic reproduction is available yet. The observed workflow was:
- Run the Windows desktop app and continue an existing, long-running task.
- Work with documents/spreadsheets, including browser automation in external Google Chrome through the ChatGPT browser extension.
- During continued work, the desktop interface intermittently disappears/reloads and returns.
- Inspect local Crashpad reports: the six records above identify the affected process as renderer.
Browser activity is context, not a confirmed trigger. A particular click or tool call has not been isolated. This was not a deliberate app restart.
Uploaded feedback/session ID: 01a07c40-4c02-7541-b954-de791a7c9d83.
What is the expected behavior?
The desktop interface should remain stable and usable throughout an active task, without repeated renderer crashes or unexpected reloads.
Additional information
Feedback was submitted through the desktop app, and the app displayed “Feedback uploaded”.
Feedback ID: 01a07c40-4c02-7541-b954-de791a7c9d83
Please use this feedback ID to correlate the diagnostic upload with the renderer crash times above.
Potentially related reports reviewed: #43347, #43437 and #43388. I have not established that either has the same root cause. In particular, #43347 describes closing the last in-app browser tab and a browser/main-process crash, whereas these records identify renderer crashes with the main process remaining alive.
#43388 describes an immediate startup reload loop on Windows 10. This report concerns intermittent crashes after the app has successfully started and an active task has been running on Windows 11.
Public content is limited to sanitized technical observations. Private document contents, screenshots, full session transcripts, local user paths and raw dumps are not included.
Activity
github-actions commentedon Sep 7, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
gazezovfm-bit commentedon Sep 7, 2026
Regarding the suggested duplicate #42323: I reviewed that report. The symptoms overlap, but it does not establish a renderer crash with the main process remaining alive, and its exact app version was not captured.
This issue adds confirmed evidence for Windows desktop version 26.901.6511.0: six Crashpad sidecars with
capture_kind=crashandptype=rendereron September 7, 2026 (UTC+05:00). The main process continued running, and a replacement renderer appeared immediately after the last recorded crash. The exact timestamps are included in the issue description.Uploaded feedback ID:
01a07c40-4c02-7541-b954-de791a7c9d83.I do not consider this a confirmed duplicate on the available evidence. These diagnostic differences do not prove a separate root cause either, so please keep this issue open for correlation with the uploaded feedback and technical triage, rather than closing it solely on symptom similarity.
gazezovfm-bit commentedon Sep 7, 2026
[Windows] Chrome debugger banner remains after ChatGPT browser work
Reported on September 8, 2026 (UTC+05:00).
Summary
After ChatGPT/Codex used my external Google Chrome browser and finished its responses, Chrome continued to display the warning that ChatGPT had started debugging the browser. Previously, I had seen this warning disappear automatically. I cannot tell from the UI whether browser control has ended or a connection remains active.
This is a user-observed change in behavior, not yet a reproducible regression with an identified root cause. The uninterrupted duration of the warning was not measured, and other possible debugger attachments have not been excluded.
Environment verified locally
Observed workflow
This Windows window-inspection failure is separate from the extension's debugger lifecycle. It does not establish that Chrome rejected a debugger detach request. Successful manual cancellation has not been verified in this investigation.
Technical findings and limits
Read-only inspection of the installed extension's background.js found an end-of-turn cleanup path: endTurnUnlocked selects the turn's tab leases, stops its sessions, and invokes detachAttachedDebuggersBestEffort before releasing, handing off, or closing tabs. The helper calls chrome.debugger.detach and uses Promise.allSettled. Automatic cleanup therefore exists in the installed implementation, but there is no runtime trace showing whether it completed for the affected turn.
The native messaging disconnect handler also contains reconnection logic. Static inspection alone cannot establish whether reconnection occurred or contributed to this incident.
Chromium source for the installed Chrome version sets a five-second dismissal delay after the last associated debugger connection is removed. A new connection cancels that timer. The banner alone therefore does not prove that an AI task is still executing. See the version-specific timer definition and banner lifecycle implementation.
Possible explanations include incomplete end-of-turn cleanup, another remaining attachment, or a re-established connection. None has been confirmed as the root cause.
Expected behavior and investigation request
Once browser work ends and no other task needs control, debugger connections should be released and the warning should disappear after Chrome's normal delay. If control is intentionally retained, the UI should clearly identify the active task and provide an understandable way to end that control.
Please check whether end-of-turn cleanup is delivered and completed after task completion, interruption, or UI recovery; whether tab ownership and attachment tracking remain consistent; and whether detach failures are logged clearly. Please also investigate the separate Windows URL-detection failure that prevented the attempted UI cleanup.
Related feedback, not a proven shared cause
Previously uploaded feedback ID: 01a07c40-4c02-7541-b954-de791a7c9d83.
Existing renderer-crash report: #43557
That report documents six renderer crashes on September 7, 2026 while the main process remained alive. No causal connection between those crashes and the persistent Chrome banner has been established. The hourly GitHub monitor is configured to use the public API and does not require a Chrome session.