Codex Desktop in-app Browser crashes the main app during webview navigation

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

• #29770
• #29585

Powered by Codex Action

I can reproduce the same issue on my Windows machine.

Environment:

• Codex Desktop: 26.623.5546.0
• Auth: API key
• OS: Windows 11
• In-app browser: enabled at the time of repro

Repro steps:

1. Open Codex Desktop.
2. Open the built-in in-app browser.
3. Navigate to http://192.168.101.123/train/
4. Within about 1-2 seconds, Codex exits/crashes and restarts.

What I observed:

• This is reproducible on multiple PCs.
• The logs repeatedly show:

"remote control requires ChatGPT authentication; API key auth is not supported"

• The browser webview reaches dom-ready for the target URL shortly before the app exits.
• No standard Windows Error Reporting dump was generated in my case.

This looks consistent with the same in-app Browser/webview crash path described above. If needed, I can provide additional log excerpts and timestamps.

I have the same issue, is there a solve yet?

I can reproduce the same in-app Browser crash on a substantially newer Windows build.

Environment

• Codex / ChatGPT Desktop package: OpenAI.Codex_26.707.3748.0_x64__2p2nqsd0c76g0
• Codex app-server: 0.144.0-alpha.4
• OS: Windows 11
• Target URL: http://127.0.0.1:5174/admin/tournaments
• Antivirus control test: Norton was fully inactive during reproduction and recorded no detection or blocked process

Reproduction

1. Start Codex Desktop.
2. Submit a workspace-only prompt that does not use the integrated browser.
3. The app remains stable.
4. Submit a prompt that causes Codex to open the local application in the integrated browser.
5. After approximately 20–30 seconds, the complete ChatGPT.exe process disappears.

This is not only a failed turn or a closed browser pane. The entire desktop process terminates.

Control tests

• Workspace-only prompts remain stable.
• The crash is reproducible when the integrated browser is used.
• The same local application can be opened separately in an external browser.
• Norton was inactive and produced no new security event.
• Windows Settings → Apps → ChatGPT → Advanced options → Repair was already performed.
• Windows was restarted afterward.
• The crash still reproduces.

Log evidence

The desktop log shows:

• normal app startup
• successful spawn of the bundled codex.exe
• successful app-server initialization
• browser sidebar / WebView activity for the localhost URL
• abrupt end of the log without a normal shutdown sequence

The last browser-related log messages include:

Failed to upsert Browser Use PiP content

A Crashpad dump is present under:

...\Codex\web\Codex\Crashpad\reports\

Expected behavior

The integrated browser should open and inspect the localhost application without terminating the entire desktop app.

Actual behavior

Using the integrated browser causes the complete desktop process to terminate after approximately 20–30 seconds.

I can provide the relevant redacted desktop log and Crashpad dump privately if a maintainer requests them.

I can reproduce this on the current Windows Store build and have a confirmed local mitigation that may narrow the native crash boundary.

Environment

• Store package: OpenAI.Codex_26.707.3748.0_x64__2p2nqsd0c76g0
• Windows: 10.0.26200, x64
• Electron/Chromium: 150.0.7871.101
• GPU: NVIDIA GeForce RTX 5070 Ti, driver 32.0.15.9174

Reproduction evidence

The desktop app exited twice immediately after opening the right-panel browser and attaching its webview. The relevant UTC crash windows were 20:13:12 and 21:41:28 on 2026-07-10.

Both logs ended in the same sequence:

1. IAB_LIFECYCLE renderer created browser sidebar webview
2. IAB_LIFECYCLE queued browser sidebar webview route
3. mcp_app_sandbox.attach_unmatched ... urlProtocol=invalid
4. IAB_LIFECYCLE runtime attached browser sidebar webview
5. In one run, browser sidebar dom-ready for the redirected local page
6. Abrupt end of the main-process log with no normal shutdown, WER report, or Crashpad dump

As noted in the original report, mcp_app_sandbox.attach_unmatched appears to be incidental: the MCP sandbox listener observes the non-MCP browser webview before the browser-sidebar listener handles it.

Confirmed local mitigation

In the packaged main bundle, the browser sidebar's did-attach-webview listener synchronously calls the internal browser-page attach function. That path reaches webContents.loadURL(...) before Electron has returned from dispatching did-attach-webview.

I patched only that boundary to defer browser-page initialization by one event-loop turn:

setImmediate(() => {
  if (!webContents.isDestroyed()) attachWebview(webContents, route);
});

After repacking the ASAR and relaunching the same build, the in-app Browser opened and navigated successfully without crashing. The unpatched build had failed twice at this boundary; the deferred build passed the same open/navigation flow.

This suggests a native Electron/Chromium re-entrancy or lifetime issue when initializing/navigating the guest synchronously from did-attach-webview. Moving the attach call to the next turn is a small candidate fix worth testing in the source build.

I can provide redacted log tails or the exact build fingerprint privately if useful.

Confirming this exact crash remains reproducible on current Microsoft Store builds 26.707.3563.0 and 26.707.3748.0 (Windows 11 25H2).

Across 12 observed Browser-sidebar sessions, webview creation preceded desktop exit by 6–16 seconds. Multiple current-build dumps show chrome.dll 0xC0000005 and a null read at 0x558.

The current-build timing evidence, sanitized analysis, and affected-session feedback ID are in #32334. I’m closing that report as a duplicate so this investigation stays centralized here.

Confirming this exact native crash on the current Windows release. Three local dumps match the existing chrome.dll access-violation signature, including the read at 0x558.

Environment

• Product: ChatGPT desktop app, powered by Codex & OWL
• About version: 26.707.31428
• Release date shown in About: 10 Jul 2026
• Microsoft Store package: OpenAI.Codex_26.707.3748.0_x64__2p2nqsd0c76g0
• OS: Microsoft Windows 11 IoT Enterprise LTSC 2024, version 24H2
• OS build: 10.0.26100.8655
• Architecture: x64 (64-bit)
• Browser path: built-in/in-app Browser Use
• Target type: ordinary public HTTPS documentation page

This confirms that the crash is not limited to the Windows Insider/build 26200 environments mentioned elsewhere in this issue.

Reproduction

The app crashed three times on 2026-07-11 while Browser Use was navigating and inspecting a public documentation page.

Observed sequence:

1. A Codex task used the built-in browser to inspect a public HTTPS page.
2. A follow-up instruction resumed the pending Browser Use operation.
3. The browser navigated to or inspected the page.
4. The complete ChatGPT desktop process terminated.

The follow-up instruction was not itself the trigger. It resumed the same built-in-browser workflow, which exposed the crash.

The failure recurred after restarting the app.

Expected behavior

Browser Use should navigate and inspect the page without terminating the desktop application. A browser or WebView failure should be isolated to the browser operation and returned as a structured error.

Actual behavior

The complete ChatGPT desktop process terminates during or shortly after the built-in browser's WebView navigation and inspection path.

Native crash signature

All three minidumps have the same signature:

Exception:       0xC0000005 (access violation)
Operation:       read
Invalid address: 0x558
Thread:          CrBrowserMain
Fault module:    chrome.dll
Fault offset:    chrome.dll+0x2ec6e66

Update 2026-07-12: persisted-state trigger isolated

I completed a controlled A/B investigation using the same environment described above.

Findings

1. Clean isolated Codex profiles remained stable during both public HTTPS and localhost navigation.
2. GPU-enabled and GPU-disabled runs were both stable.
3. Copying the production in-app Browser partition into an otherwise clean profile reproduced the complete app exit.
4. Replacing only its extension store and excluding disposable caches did not resolve it.
5. Replacing the entire dedicated in-app Browser partition with an empty one resolved the crash.

This narrows the trigger on this machine to persisted state somewhere inside:

%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\
LocalCache\Roaming\Codex\web\Codex\Default\Partitions\codex-browser-app

Confirming the same native crash on the current Microsoft Store build, with two independent Crashpad dumps and a feature-gated A/B mitigation.

Environment

• Store package: OpenAI.Codex_26.707.3748.0_x64__2p2nqsd0c76g0
• Desktop release reported by logs: 26.707.31428
• Host executable: ChatGPT.exe from the OpenAI.Codex package
• Chromium/Electron file version: 150.0.7871.101
• OS: Windows 10 Enterprise 21H2 x64, 10.0.19044.1889

Native dump evidence

Two separate in-app Browser crashes on 2026-07-12 produced the same native signature:

• Exception: 0xC0000005 read access violation
• Faulting module: bundled chrome.dll
• Faulting offset in this build: chrome.dll+0x2ec6e66
• rcx=0; attempted read at 0x558
• Failure bucket: NULL_CLASS_PTR_READ_c0000005_chrome.dll!Unknown
• Failure hash: {74d388af-6d1f-21b1-987e-9640e41d45b8}

The two process uptimes were approximately 99 seconds and 23m26s. The second dump's process peak commit was about 651 MB; the machine still had about 25 GB of available physical memory, with no Resource-Exhaustion event around the crash. This does not appear to be OOM.

Both crashes followed the same app lifecycle:

1. Browser Use guest webContents/webview attached.
2. registered debugger listener.
3. The target page reached dom-ready.
4. [browser-use-pip] Failed to upsert Browser Use PiP content backend=iab tabID=1.
5. The main browser process crashed about 1.3 seconds later.

This matches the PiP/webview sequence also reported in #32040 and extends the original 0x558 signature to Chromium 150 / the current Store build.

Confirmed mitigation / A-B result

Editing only:

[plugins."browser@openai-bundled"]
enabled = false

was not durable: bundled-plugin reconciliation reinstalled/re-enabled Browser on restart.

The narrow, persistent mitigation was:

[features]
in_app_browser = false

The bundled Browser plugin was then removed while the separate Chrome backend remained enabled (browser_use_external=true / Chrome plugin installed).

After restarting the desktop app, the log reports only:

browser_use_availability_resolved available=false browserPane=false reason=browser-pane-disabled

During repeated post-restart sampling there were zero:

• browser_use_iab_backend_startup_started/ready
• browser-sidebar webview attachments
• debugger listeners
• new Crashpad dumps

I am not attaching the full logs or dumps publicly because they may contain local paths and thread metadata, but sanitized debugger output can be provided privately if a maintainer requests it.

Fresh Windows reproduction on the current Store build. This appears to match the in-app Browser/WebView crash described here, with an additional session-recovery failure after the first crash. Related: #32653 (missing custom-tool output after restart) and #32399 (Browser Use debugger/webview crash).

<details>
<summary>Sanitized environment, timeline, and log evidence</summary>

Environment

• Codex Desktop package: 26.707.6957.0
• Desktop client reported to app-server: 26.707.51957
• Codex app-server/CLI: 0.144.0-alpha.4
• Bundled Browser plugin: 26.707.51957
• Windows 11 Home 10.0.26200, build 26200, x64
• 31.4 GB RAM
• ChatGPT Pro ($100/month)
• Home network; no VPN or proxy
• Model: gpt-5.6-sol, high reasoning

Reproduction

1. A task initialized the bundled Browser Use runtime.
2. It created an in-app browser tab and navigated to a permission-gated GitHub repository Settings URL.
3. It requested tab.playwright.domSnapshot() through mcp__node_repl__js.
4. The sidebar reached dom-ready for the real GitHub URL.
5. The entire Codex Desktop process tree disappeared; the desktop log ended without a normal shutdown.
6. After relaunching Codex and resuming the same thread, the persisted rollout contained the custom_tool_call but no matching custom_tool_call_output.
7. Every subsequent sampling pass logged Custom tool call output is missing for call id: <redacted>.
8. Reconnecting Browser Use and navigating to the same GitHub Settings URL was followed by a second full Desktop termination.

Timeline (UTC)

• 2026-07-12T22:37:30.502Z: Browser Use navigation/snapshot custom tool call persisted.
• 2026-07-12T22:37:31.237Z: mcp_app_sandbox.attach_unmatched guestWebContentsId=2 url=undefined urlProtocol=invalid.
• 2026-07-12T22:37:32.174Z: browser sidebar dom-ready at the real GitHub URL.
• First Desktop log ends; no tool output persisted.
• 2026-07-12T22:38:20Z: Codex Desktop relaunched.
• 2026-07-12T22:43:39Z, 22:43:51Z, 22:44:02Z, 22:44:10Z: repeated codex_core::util missing-output error.
• 2026-07-12T22:44:02.655Z: No ChatGPT browser route is available for browser session <redacted>.
• 2026-07-12T22:44:09.198Z: second mcp_app_sandbox.attach_unmatched.
• 2026-07-12T22:44:09.983Z: GitHub Settings page dom-ready.
• 2026-07-12T22:44:10.149Z: the second tool call returned a signed-out/404 DOM snapshot.
• The app terminated again; the next Desktop instance started at 2026-07-12T22:45:17Z.

Negative evidence

• No matching Windows Error Reporting report.
• No Windows Application Error / Windows Error Reporting event.
• No %LOCALAPPDATA%\CrashDumps dump.
• No Crashpad report; only Crashpad\settings.dat.
• No system-wide memory pressure was observed.
• This was not a Git CLI failure; the final pre-exit events were Browser sidebar WebView navigation/lifecycle events.

Interpretation

The first termination strongly matches this issue's native in-app Browser/WebView navigation failure. The orphaned custom tool call then left the resumed thread in an invalid durable state, producing the repeated error tracked in #32653. The second termination occurred after Browser Use was reattached and the same GitHub navigation was repeated.

Areas worth checking together:

• synchronous WebView initialization/navigation during did-attach-webview;
• Browser route recovery after No ChatGPT browser route is available;
• atomic persistence of custom tool call + output;
• resume-time normalization of orphaned custom tool calls;
• why this failure bypasses both Crashpad and WER.

A private support package containing the full report, sanitized evidence file, hashes, exact thread/turn/call IDs, and local source-artifact locations is being submitted separately. Raw rollout/database files are not posted publicly because they contain user prompts, local paths, and private project context.

</details>

Revalidated on a newer Windows Store build and the issue is still present.

Environment

• Codex Desktop package: OpenAI.Codex_26.707.8168.0_x64__2p2nqsd0c76g0
• OS: Windows 11 x64
• Launch mode: normal Microsoft Store launch
• Special Chromium/debugging arguments: none
• Test URL: https://example.com/

Result

The official Codex Desktop application exited while Browser Use was loading the page, before the one-minute stability check could complete. No matching Windows Error Reporting event, Application Error, or Codex/ChatGPT crash-dump metadata was found during the captured window.

This was initially investigated as a possible problem in a locally patched RTL copy because the first observed failures occurred there and some early Original runs succeeded. Repeated control tests later showed that the official Original application also fails, both with remote debugging and during a normal launch. The earlier successful runs appear to have been intermittent and led to an incorrect initial attribution to the RTL patch.

A rebuilt RTL copy sourced from the exact same 26.707.8168.0 package also exited on the same page, but replacing its patched app.asar with the official unmodified asset had already ruled out the RTL renderer injection as the cause.

Full sanitized investigation notes and the side-by-side revalidation are documented here:

https://github.com/aviad-benhamo/tool-codex-rtl-patch/issues/12

I can independently reproduce this crash on Windows, including on a newer
Codex App build.

Environment:

• Codex App: 26.707.8168.0
• Also reproduced previously on: 26.707.6957.0
• Chromium: 150.0.7871.115

Observed behavior:
Browser Use opened a localhost page during a repository audit. The page
reached DOM-ready, and the entire Codex desktop app then silently exited.
There was no error dialog.

Native dump signature:

• Process type/thread: browser / CrBrowserMain
• Exception: 0xC0000005, read access violation
• Faulting module: chrome.dll
• Fault location: chrome.dll+0x2e08f46
• RCX: 0x0
• Invalid read address: 0x558
• Instruction: mov rax, qword ptr [rcx+0x558]

Windows recorded AppModel-Runtime Event ID 217 at the same timestamp,
showing destruction of the OpenAI.Codex AppX container.

The matching Codex logs add the following sequence immediately before the
crash:

1. A Browser Use route was initially associated with the real conversation.
2. The route was then reassigned to a temporary client-new-thread identifier.
3. Browser Use later reported:

"No ChatGPT browser route is available for browser session ..."

1. Codex created a replacement hidden in-app browser webview.
2. The target localhost page reached DOM-ready.
3. The logs reported:

"Failed to upsert Browser Use PiP content"

1. The main Chromium process crashed approximately one second later.

The issue persisted after updating Codex and rebuilding/resetting the
Browser plugin cache. I am not claiming a verified completely clean-profile
reproduction.

I have the matching:

• Crashpad minidump
• t0/t1/t4 desktop logs
• AppModel-Runtime Event 217 screenshot
• affected Codex session information

I can provide the full files privately to OpenAI maintainers. Public copies
would be redacted to remove local paths, project details, and session IDs.

4 times today. Only bothered to get 3 investigations from SOL updated app yesterday (latest version as of now). seem to also point at in-app browser

high level speculative findings: (QUOTES)

The crash was most likely a Codex desktop renderer/lifecycle failure—not the shell command. The desktop log repeatedly showed stale-worktree Git polling failures while the in-app browser and another heavy image-generation task were active. Windows recorded no crash exception, WER event, or out-of-memory condition, so the exact native failure remains unconfirmed. The final command was only a small read-only rg search.

AND

The logs do not show a Windows crash exception or out-of-memory event. The strongest evidence is an app-side failure loop: Codex repeatedly polled Git diff state for a worktree that had already been removed (Failed to resolve Git object directory), while the in-app browser guest and another heavy concurrent task were active. The process then restarted abruptly. The last shell command in this task was a small read-only search, so it was not the direct cause.
I’m recording this as a “likely app renderer/lifecycle failure, not a confirmed shell-command crash,” with the concrete avoidance rules: keep this task attached to a live worktree, avoid large DOM/tool outputs, and use narrow targeted browser reads only.

AND

So the key bug is: Codex preserves the task’s original project grouping even after the agent creates or moves into a dedicated worktree. After a crash, you return to the new worktree group, while the task remains hidden under the old group.
About the crashes: I cannot prove one single root cause, but the local logs show a serious repeatable pattern:
The two interrupted tasks processed roughly 19.3 million and 20.75 million cumulative tokens.
The Codex log database is approximately 866 MB.
The first run recorded a streaming disconnect before the app process disappeared.
The second run recorded multiple MCP/plugin child processes terminating during task resume; the Codex process then ended around 20:18 and restarted around 20:21.
No clean task-completion event was written.
There is no matching Windows Codex application-fault event, suggesting an abrupt Codex app/app-server lifecycle failure rather than a normal task error.
The long-running, tool-heavy task—browser automation, VM operations, huge accumulated context, repeated MCP resumes—is very likely triggering or amplifying the instability. That is an evidence-based inference, not a confirmed OpenAI root cause.

plz fix! :) ta.

This issue persists; it is easily triggered whenever the built-in web browser is used for browsing. The built-in browser is essentially unusable—whenever you ask Codex to generate a webpage (especially a single-file HTML page), it tends to use the built-in browser to preview the result, and—boom!—it crashes.

Reproduced again on a newer Codex Windows build.

Environment

• Codex AppX: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
• Codex version: 26.707.9981.0
• Windows 11 x64, OS build 10.0.26200
• The Codex package update was installed earlier the same evening.

Reproduction evidence

The main desktop app exited twice during the same Browser Use workflow:

1. 20:21:14 local time — the in-app browser attached a sidebar webview and navigated to http://localhost:3000/.

• Immediately beforehand, the desktop log repeatedly reported:
• No ChatGPT browser route is available for browser session
• mcp_app_sandbox.attach_unmatched ... url=undefined urlProtocol=invalid
• The final line was:
• [browser-use-pip] Failed to upsert Browser Use PiP content backend=iab tabID=1
• Windows recorded the Codex AppX container as destroyed at 20:21:15.

1. 20:30:17 local time — after restarting Codex, Browser Use attached another sidebar webview and navigated to an HTTPS deployment.

• The same missing-route and attach_unmatched warnings occurred.
• The destination returned a Chromium TLS error page, but the app exited immediately afterward.
• Windows recorded the Codex AppX container as destroyed at 20:30:18.

The HTTPS/TLS failure does not appear to be the root cause because the first exit reproduced against a healthy localhost page.

Crash artifact observations

• Desktop and app-server logs stop abruptly without an orderly quit sequence.
• No matching Windows Application Error, Application Hang, or WER crash event was recorded.
• No new Crashpad report or user-mode crash dump was produced.
• Microsoft Defender and Code Integrity recorded no intervention.
• No running Codex task issued taskkill, Stop-Process, or another process-termination command.

This confirms that the in-app Browser/webview crash still reproduces in 26.707.9981.0. The current workaround is to avoid IAB/Browser Use and perform verification in external Chrome or a separate Playwright process.

Independent reproduction on the current Windows Store build, with a mitigation A/B result.

Environment

• Codex AppX: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
• Codex app-server: 0.144.2
• Windows 11 x64, OS build 10.0.26200

Observed timeline

Five spontaneous full-app exits occurred during one evening. In every case, the final 2–6 seconds of the desktop log contained the in-app Browser sidebar lifecycle: webview creation/attachment, page open/mapping, and in some runs dom-ready, followed by an abrupt log end. Windows AppModel-Runtime Event ID 217 recorded destruction of the Codex AppX container at each matching time.

The reproductions included both localhost and public HTTPS pages, so they were not tied to one destination.

Negative evidence

• No orderly shutdown sequence
• No matching WER/Application Error event or Crashpad dump
• No Microsoft Defender detection, quarantine, block, or Controlled Folder Access event
• About 36 GB of physical memory remained available

Mitigation A/B result

I set [features] in_app_browser = false, allowed bundled-plugin reconciliation to remove/disable the Browser plugin, and kept the separate Chrome integration enabled. After restarting Codex:

• codex features list reported in_app_browser ... false
• no browser-sidebar webview creation/attachment/dom-ready events occurred
• no further AppModel Event 217 was recorded during the observation window

This provides another reproduction on 26.707.9981.0 and further separates the crash from Defender or resource pressure. External Chrome remains a viable workaround. I can provide sanitized log tails privately if a maintainer requests them.

Independent reproduction on the current Windows Store build, with a mitigation A/B result. ### Environment Codex AppX: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0 Codex app-server: 0.144.2 Windows 11 x64, OS build 10.0.26200 ### Observed timeline Five spontaneous full-app exits occurred during one evening. In every case, the final 2–6 seconds of the desktop log contained the in-app Browser sidebar lifecycle: webview creation/attachment, page open/mapping, and in some runs dom-ready, followed by an abrupt log end. Windows AppModel-Runtime Event ID 217 recorded destruction of the Codex AppX container at each matching time. The reproductions included both localhost and public HTTPS pages, so they were not tied to one destination. ### Negative evidence No orderly shutdown sequence No matching WER/Application Error event or Crashpad dump No Microsoft Defender detection, quarantine, block, or Controlled Folder Access event About 36 GB of physical memory remained available ### Mitigation A/B result I set [features] in_app_browser = false, allowed bundled-plugin reconciliation to remove/disable the Browser plugin, and kept the separate Chrome integration enabled. After restarting Codex: codex features list reported in_app_browser ... false no browser-sidebar webview creation/attachment/dom-ready events occurred no further AppModel Event 217 was recorded during the observation window This provides another reproduction on 26.707.9981.0 and further separates the crash from Defender or resource pressure. External Chrome remains a viable workaround. I can provide sanitized log tails privately if a maintainer requests them.

same error

Summary
On Codex Desktop for Windows, opening the built-in in-app Browser in a specific persisted conversation causes the entire Codex application to silently exit.
The issue reproduced twice across two separate Codex processes. In both reproductions, the desktop logs show that the active persisted thread ID and the browser sidebar route ID do not match:
The active Codex thread and Browser backend use the persisted thread ID.
The browser sidebar remains registered under a stale client-new-thread:<uuid> ID.
Browser API requests fail with No ChatGPT browser route is available.
A Browser Use tab is subsequently created through the stale route.
The WebView emits mcp_app_sandbox.attach_unmatched.
The sidebar reaches dom-ready on about:blank.
The desktop log ends abruptly and Windows destroys the entire Codex AppX container.
There is no normal shutdown sequence, Windows Application Error event, WER crash report, or Crashpad dump.
Steps to reproduce
Update Codex Desktop to 26.707.9981.0.
Open the affected persisted conversation.
Ask Codex to use the built-in Browser.
Wait for the Browser Use sidebar/WebView to open.
The Codex window silently disappears.
Restart Codex and reopen/resume the same conversation.
Retry the Browser operation.
Codex silently exits again.
Observed reproduction rate for this conversation: 2/2.
Expected behavior
The built-in Browser should open and remain associated with the active persisted thread.
If the browser route or WebView cannot be created, Codex should return a recoverable Browser error without terminating the entire desktop application or interrupting the active task.
Actual behavior
The Browser backend starts successfully, but the Browser sidebar is registered under a stale provisional conversation ID.

Reproducing on Store build 26.707.9981.0 (arm64), Windows 11. This build is a regression for me — the desktop app worked on the prior build and began crashing immediately after the Microsoft Store auto-updated to 26.707.9981.0.

Symptom: app launches, then the entire process exits ~8–14s later, with no error dialog (Crashpad swallows it; Windows Error Reporting logs nothing). It's stable while sitting at the sign-in screen and crashes once a workspace/thread loads.

Native signature (matches this thread): 0xC0000005 read access violation, thread CrBrowserMain, faulting module bundled chrome.dll, RCX=0, invalid read at 0x558. The last main-process log line before every crash is IAB_LIFECYCLE registered browser sidebar thread.

Mitigations tested — all still crash identically on this build:

| Attempt | Outcome |
|---|---|
| [features] in_app_browser = false | Log shows browser_use_availability_resolved available=false … reason=browser-pane-disabled, but IAB_LIFECYCLE still registers the sidebar webview → crash |
| Disable browser@openai-bundled + chrome@openai-bundled plugins | Same — pane reports disabled, sidebar still registers → crash |
| Disable hardware acceleration (hardware_acceleration_mode.enabled=false) | Crash unchanged |
| Wipe Chromium profile / partition | Crash unchanged |
| Full clean uninstall + reinstall (empty profile, not signed in → signed in) | Stable at login screen; crashes as soon as a thread loads |

Takeaway: the browser-sidebar webview registration appears unconditional — no feature flag or plugin toggle prevents it from initializing, so there's no config-level workaround on this build. Only the codex CLI is unaffected.

#33202 is related

Independent Windows reproduction

I am experiencing the same in-app Browser crash in the ChatGPT/Codex desktop application.

Environment

• ChatGPT desktop client: 1.2026.190
• OS: Windows 11 x64 (10.0.26200)
• In-app feedback ID: no-active-thread-019f7eba-6dad-71a1-a18d-eecf67d899e1

Observed behaviour

• Opening the internal/in-app Browser directly causes the entire desktop application to crash/close.
• The same failure occurs when an active task invokes the internal Browser.
• When the application exits, every other process/task running at that time stops abruptly and does not continue in the background.

Reproduction

1. Open the ChatGPT/Codex desktop application on Windows.
2. Start a task/process.
3. Open the internal Browser, or allow the active task to invoke it.
4. The entire application exits and all running work is interrupted.

Expected behaviour

The internal Browser should open without terminating the desktop host. If the Browser/WebView fails, it should return a recoverable error while the application and other running tasks remain active.

This was also reported through the application's feedback uploader. The symptoms and task interruption appear closely related to #33202.