Codex Desktop crashes after in-app Browser sidebar webview creation on Windows

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?

1. Open or resume a Codex task containing an in-app Browser / Browser Use sidebar tab.
2. Have the sidebar display a local page at http://127.0.0.1:3005 (observed route: /carnivore-diet-documentary).
3. Codex logs creation/attachment of the Browser sidebar webview.
4. 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:

• #31353 reports Windows instability around Browser/Computer Use/node-repl, but its c0000409/BEX64 signature differs.
• #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.