[Windows][26.803.10989.0] Multiple embedded browser tabs accumulate WebView2 processes and crash Codex when a task finishes

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

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?

  1. Start Codex Desktop on Windows.
  2. Run a long task that uses the right-side embedded browser repeatedly.
  3. Open/navigate several embedded-browser pages during the same task (heavy pages such as Figma make the issue easier to reproduce).
  4. Leave multiple embedded pages alive or repeatedly create new browser tabs instead of reusing one.
  5. Let the agent finish the task and finalize/release its browser tabs.
  6. Codex Desktop intermittently exits at or immediately after task completion.
  7. 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.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 15 days ago

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

  • #38175

Powered by Codex Action

ArielAvila112 · 13 days ago

Additional reproduction confirming that this issue persists on a newer Windows build:

  • Codex Desktop x64 version: 26.810.4967.0
  • Crash time: 2026-08-14 10:56:39 (UTC-6)
  • Trigger: the agent used the in-app Browser to test a localhost web application, then closed/released the Browser tab at the end of the task. The entire desktop application exited immediately afterward.
  • Crashpad sidecar ID: 4a47c927-e115-4195-9b64-80f80a53e7b3
  • Sidecar metadata: {"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}
  • The final app-log sequence was Browser target-close, renderer disposal, guest teardown, then repeated ResizeObserver loop completed with undelivered notifications entries before the process disappeared.
  • No corresponding Application Error or Windows Error Reporting event was recorded.

The same workflow also crashed earlier that day at 09:50:26 on version 26.803.10989.0, with Crashpad sidecar ID af53bcfa-dd34-4945-97aa-ac3064c3c985 and the same ptype: "browser" metadata.

This suggests that the embedded-browser cleanup/lifecycle crash persists across the update from 26.803.10989.0 to 26.810.4967.0. Raw logs and dumps are intentionally not attached because the affected session contains private credentials and project data.