[Windows][Codex Desktop] In-app browser crashes Codex when opening localhost #38175

Activity

1. SolusKossi

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Aug 12, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   browser

   on Aug 12, 2026
3. github-actions commented on Aug 12, 2026

   

   github-actionsBot

   on Aug 12, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Codex App window repeatedly turns completely blank after renderer crashes #37968
   • [RETRACTED] Withdrawn by reporter - incorrect analysis #38098

   Powered by Codex Action
4. kcwl-gona commented on Aug 16, 2026

   

   kcwl-gona

   on Aug 16, 2026 – with ChatGPT Codex Connector

   More actions

   Confirming that this still reproduces on a newer Windows Codex Desktop build.

   Environment:

   • Codex Desktop: 26.810.7004.0 (x64)
   • Windows: 10.0.26200, x64
   • Date observed: 2026-08-17

   Reproduction:

   1. Start or keep a local web service available on 127.0.0.1.
   2. Ask Codex to use the in-app Browser for UI verification.
   3. As soon as Browser Use is invoked / the embedded browser is opened, the Codex desktop app exits or crashes.
   4. Reopening Codex and avoiding Browser Use prevents the crash.

   The behavior is reported as deterministic on this build: any Browser invocation triggers the crash. Shell/API-based checks continue to work.

   During one Browser screenshot attempt, the tool stream also logged a Statsig POST timeout to ab.chatgpt.com (10 seconds). The screenshot itself was returned, so this may only be adjacent telemetry rather than the crash cause.

   Expected:

   • Browser failures should be contained to the browser session/tab.
   • Codex Desktop should remain running, and the active task should continue.

   No project credentials, browser contents, or business data are included in this report.
5. ngflizwx-ui commented on Sep 29, 2026

   

   ngflizwx-ui

   on Sep 29, 2026 – with ChatGPT Codex Connector

   Last edited by ngflizwx-ui

   More actions

   Additional reproduction on a newer Windows desktop build.

   • Microsoft Store/MSIX package: OpenAI.Codex 26.924.2738.0 (x64).
   • Date/time: 2026-09-29, UTC+08:00. The app's Electron/Chromium browser (main) process crashed at 21:47:00, 21:54:41, and 22:05:24. The third crash occurred after a Windows reboot.
   • Each crash was preceded by the same active task opening a localhost HTML preview through Codex's in-app Browser Use webview. The page became DOM-ready at 21:46:50, 21:54:32, and 22:05:07 respectively, about 9–17 seconds before the corresponding crash.
   • Three Crashpad sidecars each contain {"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}. Windows AppModel-Runtime recorded the app container being destroyed and a later relaunch.
   • No matching Windows Application Error/WER event, Resource Exhaustion Detector event, Defender action, or retained local minidump was found in the inspected window. The app remained responsive after the last relaunch while that preview was not reopened.

   Expected: a local preview or webview failure should be isolated to the tab/operation; the desktop app and active tasks should stay running.

   This is a strong timing correlation, not proof that the HTML page itself is the native root cause. The private page URL, project path, chat identifiers/content, and raw logs are omitted.

   Follow-up investigation (same date)

   A fourth browser/main-process crash occurred at 22:35:30 UTC+08:00 while a different task was using another localhost page from the same workbench family. The tab was created at 22:34:07, Page.navigate timed out at 22:34:27, the page became DOM-ready at 22:34:45, and the debugger listener was registered again at 22:35:22. The fourth Crashpad sidecar also reports ptype=browser.

   The user and earlier logs confirm the same workbench worked earlier that day on the same installed app version (app release 26.924.22138, MSIX 26.924.2738.0). This is not evidence of an app update between successful use and these failures.

   Task call records show explicit ax.write() calls in the operations spanning crashes 1, 2, and 4; the recorded operation for crash 3 was navigation without an explicit ax.write(). Thus accessibility extraction is an investigation lead, not an established common cause.

   A later HTTP-only measurement of the live workbench returned 158,143,306 bytes with about 23.2 seconds to response headers. We found and locally removed an unnecessary full-project deep copy in the workbench's save-baseline calculation. That calculation fell from 14.7 to 3.1 seconds; all 46,766 hashes matched, and 37 save-related tests passed. An isolated HTTP handler then served the identical response length in 13.5 seconds. This is a page-performance mitigation only: we have not reproduced the page in Codex again and do not claim the native crash is fixed. Earlier incidents also loaded quickly, so the navigation timeout alone does not explain all four crashes.

   No native stack or retained minidump is available locally. Private pages, assets, task identifiers and raw logs remain omitted.