Codex Desktop crashes when the in-app Browser opens with multiple side chats running
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?
- Open Codex Desktop on Windows.
- Start approximately four side chats/tasks.
- Let the tasks run concurrently.
- Have one task open a page using the Codex in-app Browser.
- 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_
8 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
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
26.707.9981.010.0.26200, x6432.0.15.91660.45.0.0Reproduction
The app repeatedly terminated while Codex attempted the in-app Browser handoff during a Sites workflow:
This occurred with two different targets:
file://design preview (the Browser URL policy correctly rejected the URL, but the desktop app subsequently exited); andThe deployed site builds, tests, deploys, and opens independently outside the in-app Browser.
Windows crash evidence
Windows Event Viewer recorded repeated
Application Error/MoAppCrashevents forChatGPT.exefrom theOpenAI.Codex_26.707.9981.0_x64package.Matching application-crash times on July 15, 2026 (CDT):
All captured crashes used:
0xc06d007funknownBrowser 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
10.0.26200.8655OpenAI.Codex_26.707.9981.0_x6426.707.72221150.0.7871.1150.144.2Symptom
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:
2026-07-16T00:11:06Z— the browser sidebar attached and reacheddom-readyfor a localfile://HTML dashboard. The desktop log ended abruptly 7 ms later. A replacement app session started approximately 13 seconds later.2026-07-16T00:41:02Z— the same persisted task restored the dashboard throughhttp://127.0.0.1:<port>/. The browser reacheddom-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
0xC06D007Ffaults involving the bundledserialport.nodedependency. 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 = falseis 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:
Steps to reproduce:
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.