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

Open 💬 8 comments Opened Jul 15, 2026 by wapmaster13
💡 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)?

26.707.9981.0

What subscription do you have?

PRO

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

What version of the Codex App are you using (From “About Codex” dialog)?

26.707.9981.0

What subscription do you have?

Pro

What platform is your computer?

Windows 11 Pro, build 26200, x64

What issue are you seeing?

Codex Desktop repeatedly crashes when multiple side chats are running concurrently and one of them opens the in-app Browser.

The entire Codex process disappears abruptly. There is no crash dialog or normal shutdown sequence. The running side chats are interrupted and may no longer appear after restarting the application.

This has happened at least five times. I reproduced it again while attempting to open help.openai.com through the Codex in-app Browser.

What steps can reproduce the bug?

  1. Open Codex Desktop on Windows.
  2. Start approximately four side chats/tasks.
  3. Let the tasks run concurrently.
  4. Have one task open a page using the Codex in-app Browser.
  5. When the Browser sidebar/webview is created and attached, Codex may close abruptly.

The crash is strongly correlated with opening the in-app Browser while several side chats are active.

What is the expected behavior?

The in-app Browser should open without terminating Codex Desktop.

All running side chats should continue working, and their state should remain available after the Browser sidebar is opened.

Additional information

Environment:

  • Codex Windows package: 26.707.9981.0
  • Bundled Codex CLI: 0.144.2
  • Windows 11 Pro, build 26200, x64
  • Approximately 36 GB of 64 GB RAM was free after restart

Repeated crash times on 2026-07-15, Europe/Bucharest timezone:

  • 00:15:57
  • 00:28:27
  • 01:29:36
  • 04:12:26
  • Another crash while opening the OpenAI Help Center through the in-app Browser

Immediately before several crashes, the final application log records were:

IAB_LIFECYCLE attached browser sidebar guest
IAB_LIFECYCLE host opened page
IAB_LIFECYCLE iab createTab mapped page to tab
IAB_LIFECYCLE registered debugger listener

### What steps can reproduce the bug?

No code snippet is required to reproduce this issue.

1. Open Codex Desktop on Windows 11.
2. Start four (or more). side chats/tasks and allow them to run concurrently.
3. In the side chats, ask Codex to open or inspect a webpage using the in-app Browser.
4. Wait for the Browser sidebar/webview to be created.
5. Codex Desktop may close abruptly immediately after the Browser webview is attached or its debugger listener is registered.

I reproduced the crash again by opening `https://help.openai.com/` through the Codex in-app Browser.

The issue has occurred repeatedly, including when 3–9 task/session IDs were present in the final section of the application log. It is most consistently reproduced with four actively running side chats.

For the most recent fully logged crash, the final records were:

```text
IAB_LIFECYCLE attached browser sidebar guest
IAB_LIFECYCLE host opened page
IAB_LIFECYCLE iab createTab mapped page to tab
IAB_LIFECYCLE registered debugger listener

### What is the expected behavior?

_No response_

### Additional information

_No response_

View original on GitHub ↗

8 Comments

github-actions[bot] contributor · 6 days ago

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

  • #33183

Powered by Codex Action

wapmaster13 · 5 days ago

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

jetblackrlsh · 5 days ago

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.

wapmaster13 · 5 days ago

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

BLWesley · 5 days ago

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.

wapmaster13 · 4 days ago

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

wapmaster13 · 4 days ago

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

GiovannyPonte · 4 days ago

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.