[Windows][26.803.10989.0] Multiple embedded browser tabs accumulate WebView2 processes and crash Codex when a task finishes
What version of the Codex App are you using (From “About Codex” dialog)?
OpenAI.Codex 26.803.10989.0 (x64)
What subscription do you have?
ChatGPT subscription (exact tier is not displayed in the Codex diagnostics)
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
Codex Desktop exits after a task finishes when several pages have been opened in the right-side embedded browser.
This appears to be an embedded-browser lifecycle / cleanup failure rather than a repository or task failure:
- Codex Crashpad recorded 7 incidents during the affected sessions.
- Every remaining Crashpad sidecar reports: {"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}.
- The crashes occurred after repeated embedded-browser use, commonly when the agent task completed and browser tabs were being finalized/released.
- No corresponding Codex.exe / ChatGPT.exe Application Error was recorded by Windows Error Reporting.
- The application may close completely instead of returning a browser-tool error.
Observed resource state after repeated sidebar-browser use:
- 21 msedgewebview2 processes: approximately 974 MB working set, 823 MB private memory, 9,801 handles.
- 10 ChatGPT processes: approximately 1.7 GB working set, 1.48 GB private memory, 5,212 handles.
- System memory was not exhausted (approximately 13 GB still available and paging-file use below 1%).
The behavior becomes much more likely as more right-side embedded pages are opened. Keeping only one embedded tab, reusing it, and moving heavy sites to external Chrome substantially reduces the problem.
Related but not identical:
- #35352 describes an embedded-browser GPU subprocess crash and SwiftShader fallback failure.
- #34311 describes sidebar-browser crashes followed by MSIX NeedsRemediation.
- This report is specifically about tab/process accumulation and the crash occurring during end-of-task browser cleanup on a newer build.
What steps can reproduce the bug?
- Start Codex Desktop on Windows.
- Run a long task that uses the right-side embedded browser repeatedly.
- Open/navigate several embedded-browser pages during the same task (heavy pages such as Figma make the issue easier to reproduce).
- Leave multiple embedded pages alive or repeatedly create new browser tabs instead of reusing one.
- Let the agent finish the task and finalize/release its browser tabs.
- Codex Desktop intermittently exits at or immediately after task completion.
- Restart Codex and inspect its Chromium Crashpad reports; a new sidecar is created with ptype: "browser".
The issue has reproduced repeatedly across separate task runs, with 7 browser Crashpad entries observed over one evening.
Workaround:
- Keep at most one embedded tab.
- Reuse the same tab for navigation.
- Close intermediate pages progressively instead of all at task completion.
- Use external Chrome for heavy web applications.
What is the expected behavior?
Embedded-browser tabs and their renderer/GPU processes should be reclaimed as they are closed or released.
If a renderer, GPU process, or tab-finalization operation fails, Codex should return a scoped browser-tool error and keep the desktop application alive. Finishing an agent task must not terminate the whole application.
Additional information
Environment:
- Codex Desktop: OpenAI.Codex 26.803.10989.0 (x64)
- Windows: Microsoft Windows NT 10.0.26200.0 x64
- WebView2 Runtime: 151.0.4129.78
- GPU: NVIDIA GeForce RTX 4070 Ti
- NVIDIA driver: 591.86
- GPU memory observed during diagnosis: approximately 6.9 / 12 GB
- A historical nvlddmkm event exists on the machine, so GPU acceleration may amplify the failure, but the strongest evidence is the repeated Codex Crashpad ptype: browser records plus WebView2/process accumulation.
No private project files, credentials, cookies, or crash dumps are attached. Full Crashpad dumps had already been uploaded or cleaned; only the sidecar metadata remained.
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Additional reproduction confirming that this issue persists on a newer Windows build:
26.810.4967.04a47c927-e115-4195-9b64-80f80a53e7b3{"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}target-close, renderer disposal, guest teardown, then repeatedResizeObserver loop completed with undelivered notificationsentries before the process disappeared.The same workflow also crashed earlier that day at 09:50:26 on version
26.803.10989.0, with Crashpad sidecar IDaf53bcfa-dd34-4945-97aa-ac3064c3c985and the sameptype: "browser"metadata.This suggests that the embedded-browser cleanup/lifecycle crash persists across the update from
26.803.10989.0to26.810.4967.0. Raw logs and dumps are intentionally not attached because the affected session contains private credentials and project data.