Codex Desktop crashes when the in-app Browser opens with multiple side chats running

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

• #33183

Powered by Codex Action

It's extremely annoying, please fix this ASAP, I can't even use the app...

Independent reproduction with the same current Windows app build.

Environment

• Codex Windows app: 26.707.9981.0
• OS: Windows 11 Home Single Language, version/build 10.0.26200, x64
• Physical GPU: NVIDIA GeForce RTX 4060 Laptop GPU, driver 32.0.15.9166
• Virtual display: Parsec Virtual Display Adapter, driver 0.45.0.0

Reproduction

The app repeatedly terminated while Codex attempted the in-app Browser handoff during a Sites workflow:

1. Initialize the Codex-controlled in-app Browser.
2. Select/create the in-app Browser tab.
3. Make the Browser visible.
4. Navigate the tab.
5. The entire Codex desktop app exits and the active task is interrupted.

This occurred with two different targets:

• a local file:// design preview (the Browser URL policy correctly rejected the URL, but the desktop app subsequently exited); and
• a deployed HTTPS Sites URL.

The deployed site builds, tests, deploys, and opens independently outside the in-app Browser.

Windows crash evidence

Windows Event Viewer recorded repeated Application Error / MoAppCrash events for ChatGPT.exe from the OpenAI.Codex_26.707.9981.0_x64 package.

Matching application-crash times on July 15, 2026 (CDT):

• 10:49:16
• 11:10:27
• 11:11:41
• 11:12:11

All captured crashes used:

• Exception code: 0xc06d007f
• Faulting module: unknown
• Same Windows Error Reporting fault bucket across repeated attempts

Browser runtime initialization and documentation retrieval succeeded. The failure correlated with the Browser tab/visibility/navigation handoff. A blocked URL should produce a recoverable error, and an embedded browser failure should not terminate the desktop host.

Workaround

Avoid the Codex in-app Browser and open published/local URLs in an external browser. All non-browser work continued successfully.

The Parsec virtual display adapter may be relevant to reproduction, but there is not enough evidence to identify it as the cause.

Can we get someone looking into this? I can't use my CODEX app because of this.

Independent Windows x64 reproduction — build 26.707.9981.0

Environment

• Windows 11 Pro 25H2, x64
• OS version/build: 10.0.26200.8655
• Microsoft Store package: OpenAI.Codex_26.707.9981.0_x64
• Embedded desktop/UI release: 26.707.72221
• ChatGPT.exe / Chromium version: 150.0.7871.115
• Bundled Codex CLI/app-server: 0.144.2
• More than 50 GB physical memory remained available

Symptom

The entire ChatGPT/Codex desktop process terminates without an error dialog or normal shutdown when an existing task restores or attaches its right-panel in-app Browser webview.

I confirmed two occurrences on 16 July 2026:

1. 2026-07-16T00:11:06Z — the browser sidebar attached and reached dom-ready for a local file:// HTML dashboard. The desktop log ended abruptly 7 ms later. A replacement app session started approximately 13 seconds later.
2. 2026-07-16T00:41:02Z — the same persisted task restored the dashboard through http://127.0.0.1:<port>/. The browser reached dom-ready, and the desktop log ended approximately 313 ms later. A replacement session started approximately 10 seconds later.

The final lifecycle sequence was:

IAB_LIFECYCLE renderer created browser sidebar webview
mcp_app_sandbox.attach_unmatched ... url=undefined urlProtocol=invalid
IAB_LIFECYCLE runtime attached browser sidebar webview
browser sidebar dom-ready
<abrupt end of log; no orderly shutdown>

Because both targets were entirely local (file:// and loopback), internet latency is not the cause. Normal shell, file, Git, and non-browser task activity remains stable. The immediate trigger is the embedded browser/webview attachment, possibly made more likely by several concurrent tasks.

Windows also records separate 0xC06D007F faults involving the bundled serialport.node dependency. However, the same main-process PID continues running after many of those events, so that WER problem appears separate from the terminal in-app Browser exits.

Expected behaviour

A failed browser webview attachment should close or disable the browser pane and return a recoverable error. It should not terminate the entire desktop host or interrupt other running tasks.

This appears to match #30178 and #33202. Please advise whether a hotfix is planned and whether [features] in_app_browser = false is the recommended temporary mitigation for Windows x64.

Can we get someone looking into this? I can't use my CODEX app because of this.

New steps - You just use the in-app browser and the app crashes immediately

I am seeing a very similar crash on Windows Codex Desktop.

In my case, Codex closes when a workflow opens a browser or Windows Explorer during a task. It is not only the in-app browser; it also happens when the agent attempts to open Chrome/Edge or Explorer for human review.

Environment:

• Windows
• Codex Desktop app
• Workspace: D:\Proyectos Codex\CardioGuidelinesManager
• Workflow: daily cardiovascular guideline maintenance / missing PDF review

Steps to reproduce:

1. Open Codex Desktop on Windows.
2. Open workspace D:\Proyectos Codex\CardioGuidelinesManager.
3. Ask Codex to review or download missing official guideline PDFs.
4. The task reaches a human-review step and Codex tries to open an official URL in browser or open Windows Explorer.
5. Codex Desktop closes unexpectedly.

Expected:
Codex should remain open. If browser/Explorer launch fails, it should show a recoverable error and keep the session alive.

Actual:
Codex Desktop closes/crashes and interrupts the workflow.

Impact:
This blocks my clinical-document workflow. Official cardiology guideline URLs must be reviewed manually before approving or downloading PDFs.

Workaround:
I now have to instruct Codex not to open browser, Chrome, Edge, Explorer, or any external windows, and only generate reports and URL lists.

still no fix on this yet

Additional teardown-side evidence from Windows, sanitized (no raw logs or dumps attached):

Environment: Codex Desktop OpenAI.Codex_26.803.10989.0_x64 on Windows. Crashpad recorded four consecutive browser-process crashes across two builds (capture_kind: crash, ptype: browser).

| Local time (UTC+8) | Build | IAB tabs | Teardown reason | Last page closed -> crash |
|---|---|---:|---|---:|
| 2026-08-13 02:19:01.794 | 26.803.5235.0 | 1 | session-activity-ended | 1.382 s |
| 2026-08-13 23:32:53.054 | 26.803.10989.0 | 1 | session-activity-ended | 0.740 s |
| 2026-08-14 01:48:50.423 | 26.803.10989.0 | 3, same conversation route | manual | 0.759 s |
| 2026-08-14 10:21:55.770 | 26.803.10989.0 | 2, same conversation route | manual | 0.683 s |

In all four cases, the app log shows the IAB debugger listener being unregistered before the sidebar guest/page is torn down; webContentsDestroyed=false at listener unregister. In the two multi-tab cases, multiple listeners/pages on the same route are torn down nearly simultaneously. The latest log reaches zero app/thread browser tabs after close, then the browser process crashes less than one second later.

All four logs contain missing-route activity; three also contain missing execution-context activity. There is no matching Unhandled, uncaught, or fatal JavaScript error immediately explaining the exit. Windows event records do not show resource exhaustion, a system restart, or Windows Update causing these exits. For the latest crash, Windows Update discovery/download happened only after the watchdog had restarted Codex.

This strongly suggests an IAB/browser-sidebar lifecycle teardown race rather than an OS shutdown. Possible areas to inspect:

• route refcount/removal while sibling tabs on the same route are still tearing down;
• duplicate cleanup between manual/session-end disposal and destroyed/did-detach callbacks;
• late CDP callbacks after execution-context invalidation;
• non-idempotent debugger-listener or guest/webContents cleanup.

Suggested regression matrix: 2-3 tabs on one route closing together; session-end racing manual close; context invalidation immediately before close; duplicate detach/destroy callbacks; owner-window close with multiple guests. A per-route teardown queue/mutex, last-guest refcount, generation/tombstone checks, and idempotent detach/dispose paths may help.

I do not have a local .dmp, so this evidence cannot identify the exact native exception or prove a double-free/UAF. Raw logs can be provided privately through the official feedback channel if the engineering team needs them.

Adding a later Windows x64 reproduction that continues after updating the desktop app.

Environment

• Windows 11 x64
• Microsoft Store package: OpenAI.Codex_26.810.4967.0_x64__2p2nqsd0c76g0
• Codex desktop app / ChatGPT.exe
• In-app Browser / Browser Use (IAB)

Reproduction and timing

A project task opened a staging web app through the in-app Browser, completed a short UI flow, discarded the synthetic draft, and then cleaned up the browser tab. During cleanup:

1. iab.tabs.finalize({keep:[]}) failed.
2. The subsequent tab-close call completed.
3. The desktop app exited; after restart, the task was interrupted.

The confirmed Crashpad browser-process report occurred at approximately 2026-08-14 11:56:50 America/New_York (15:56:50Z). This was on the updated 26.810.4967.0 build. A prior occurrence on the same day happened on 26.803.10989.0, so updating and restarting did not resolve it.

The browser-active task was the only task producing browser lifecycle events in the final crash window; another task had already completed. This suggests multiple concurrent side chats may increase exposure but are not required.

Sanitized evidence

The final desktop-log window contains:

• six repeated failures to upsert Browser Use PiP content: backend=iab tabID=1;
• an earlier mcp_app_sandbox.attach_unmatched warning with url=undefined urlProtocol=invalid;
• during teardown, iab rejected a tab because tabRouteKey=null;
• debugger-listener unregister, renderer/browser-sidebar disposal, guest teardown, page close, and appBrowserTabCount=0;
• the Crashpad sidecar identifies capture_kind=crash and ptype=browser.

There was no out-of-memory indication and no unknown-conversation, missing-state, or ResizeObserver error in the final crash window. The in-app Browser failure is therefore the strongest correlation, rather than Python, the other project task, or a general memory problem.

Expected behavior

A Browser/IAB PiP or route-teardown failure should be isolated to the browser tab and return a recoverable error. It should not terminate the main Windows desktop process or interrupt unrelated tasks.

Workaround

Avoid the desktop in-app Browser/Browser Use and use ordinary Chrome or another environment for browser work; the desktop app is stable when this workflow is skipped.

This looks like a later build recurrence of the Browser Use/PiP teardown failure in #32040 (closed), with lifecycle overlap with #33514 and #30178. Please consider an idempotent/serialized route, debugger-listener, guest, and PiP teardown path so a failed finalize/close cannot bring down the main app.