Repository navigation
Codex Desktop crashes after in-app Browser sidebar webview creation on Windows #32334
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.707.3748.0 (also reproduced on 26.707.3563.0)
What subscription do you have?
ChatGPT paid plan
What platform is your computer?
Windows 11 Home 25H2, build 10.0.26200.8655, x64
What issue are you seeing?
Codex Desktop repeatedly crashes after creating or restoring the in-app Browser sidebar webview.
Across 12 observed sessions on July 9-10, 2026, all 12 sessions that logged Browser sidebar webview creation ended 6-16 seconds later. Sessions with no Browser webview creation remained stable for hours. The pattern reproduced across Microsoft Store builds 26.707.3563.0 and 26.707.3748.0, with and without a debugger attached.
Every observed fatal webview navigated to http://127.0.0.1:3005. Whether a blank or unrelated page also triggers the crash has not been tested.
Confirmed native signature from multiple full dumps:
Exception: 0xC0000005 ACCESS_VIOLATION
Type: invalid pointer read
Faulting module: chrome.dll
Faulting offset: 0x2ec6e66
Invalid read address: 0x558 from a null object pointer
Failure bucket: INVALID_POINTER_READ_c0000005_chrome.dll!Unknown
Failure hash: {5cd13162-58f6-4190-dced-e6b658b0f99b}
Process: ChatGPT.exe
More than 50 GiB RAM was available during captured crashes, so system-wide memory pressure is unlikely.
What steps can reproduce the bug?
- Open or resume a Codex task containing an in-app Browser / Browser Use sidebar tab.
- Have the sidebar display a local page at http://127.0.0.1:3005 (observed route: /carnivore-diet-documentary).
- Codex logs creation/attachment of the Browser sidebar webview.
- The desktop session ends 6-16 seconds later.
Affected-session feedback ID: 019e8686-2240-7552-b47e-fc838d6cd063.
The affected turn requested a local preview and is marked interrupted after the desktop crash. Eight of the 12 observed reproductions occurred without a debugger attached.
What is the expected behavior?
Creating or restoring an in-app Browser webview must not terminate Codex Desktop. Failures in page content, authentication, autofill, WebAuthn, or sandbox attachment should remain isolated to the Browser surface.
Additional information
Environment:
- Windows 11 Home 25H2, build 10.0.26200.8655, x64
- Codex packages: 26.707.3563.0 and 26.707.3748.0
- Desktop client version in app-server logs: 26.707.31123
- Bundled Chromium: 150.0.7871.101
- Approximately 96 GiB RAM
Post-workaround incident:
After browser@openai-bundled was set to disabled and verified disabled, Codex unexpectedly exited and automatically relaunched at approximately 9:18 PM Pacific on July 10. It occurred while Chrome-extension automation was active, but timing alone does not establish a cause. No passive WER dump was available for that incident.
Evidence qualification:
One July 10 capture was contaminated when a local ProcDump supervisor terminated while attached, causing child exits with 0xC0000354 STATUS_DEBUGGER_INACTIVE. Those GPU/app-server exits are local diagnostic artifacts. The Browser conclusion is independently supported by 11 other sessions, including eight without a debugger.
Webview creation also coincided with handled 0x6BA and 0x80090016 exceptions in a Windows Hello/NGC availability probe. These appear to be handled availability results; no causal chain to the later Chromium access violation is established.
Related:
- Windows Desktop crash/hang with codex.exe MoBEX and node_repl/extension-host BEX64 after recent update #31353 reports Windows instability around Browser/Computer Use/node-repl, but its c0000409/BEX64 signature differs.
- Windows desktop app crashes on launch with code=3221225477 #19258 reports Windows exit code 3221225477 but does not establish this Browser-webview trigger.
Sanitized WinDbg text analyses and a redacted timing table are available. Raw memory dumps and complete desktop logs are intentionally excluded because they may contain credentials, environment variables, connector state, and private task content.
Activity
github-actions commentedon Jul 11, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
kevncarter commentedon Jul 11, 2026
Closing as a duplicate of #30178. This report’s current-build reproduction and sanitized evidence remain available here.
serdox commentedon Jul 12, 2026
enable hardware acceleration in chrome etc. codex fixed that for me.
OceanWhiskey98 commentedon Jul 13, 2026
I may have a related independent Windows in-app Browser crash.
My Crashpad dump also shows:
CrBrowserMain0xC0000005read access violationchrome.dllRCX0x558My precise fault location is
chrome.dll+0x2e08f46, so it differs from this report, but the null-object read pattern and in-app Browser timing appear closely related.Fuller details:
#30178 (comment)
Exact matching signature:
#32683
serdox commentedon Jul 14, 2026
enable hardware accel. in chrome. chromium issue.
AbdullahKahlon commentedon Jul 29, 2026
Likely the same root cause as #34133. On 26.721.4979.0 every crash here is preceded within seconds by CodeIntegrity Event 3033 rejecting the bundled unsigned vk_swiftshader.dll, and the browser process then fires gpu_data_manager_impl_private.cc:416: GPU process isn't usable. Goodbye.
Setting [plugins."browser@openai-bundled"] enabled = false in config.toml stops it for me — consistent with webview init being what pulls in the software-Vulkan path. Full evidence in #34133.
Worth checking your Microsoft-Windows-CodeIntegrity/Operational log for 3033 events matching your crash times.