Windows Desktop: opening in-app Browser can hang/close Codex after Browser Use PiP failure

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

• #31115
• #30624

Powered by Codex Action

Adding another Windows data point that appears to match this issue closely.

Environment:

• Microsoft Store package: OpenAI.Codex_26.707.3563.0_x64
• Desktop client version reported in logs: 26.707.31123
• Windows 11 x64, OS version 10.0.26200

I observed two consecutive full-app exits on 2026-07-10:

• 08:12:56Z (10:12:56 Europe/Warsaw)
• 08:15:12Z (10:15:12 Europe/Warsaw)

On both runs, Browser Use created and attached the browser-sidebar webview, navigated successfully to an HTTPS localhost page, and then ended with the same two records:

[browser-use-pip] Received Browser Use PiP metadata backend=iab browserID=<redacted> tabID=1 threadID=<redacted>
[browser-use-pip] Failed to upsert Browser Use PiP content backend=iab tabID=1

Those were the final two lines in each desktop log. In both cases, Windows AppModel-Runtime removed the Codex Desktop AppX container approximately two seconds later. A newly launched Codex process then had a different PID.

Unlike the original report, this machine recorded no matching Application Error/Hang/WER 1000, 1001 or 1002 event, no Crashpad report, and no resource-exhaustion event. The Codex backend also recorded no terminal panic at either boundary. This suggests that the same Browser Use/PiP sequence can terminate the desktop host without producing MoAppHang or a crash dump.

A short-lived recovery session subsequently restored the browser sidebar and repeatedly logged owner-sync/rebind activity before its log also ended. That session had no terminal exception, so I am treating it as a follow-on recovery observation rather than another confirmed PiP reproduction.

Separately, the desktop log contains handled warnings about a chat-process-notification record containing NUL bytes and failing JSON parsing. Those warnings were not the final event in either exit, so they may be unrelated.

Sanitized diagnostic evidence is attached below as codex-browser-pip-repro-sanitized.txt. It contains the crash-correlated log tails, Windows AppModel event correlation, negative WER/Crashpad/resource-exhaustion checks, and sanitization details. Conversation IDs, browser IDs, local paths, repository information, and the localhost port have been removed.

codex-browser-pip-repro-sanitized.txt

Adding a native-crash data point that appears closely related to this issue.

Environment

• Codex Desktop MSIX: 26.707.3748.0 (internal log release: 26.707.31428)
• ChatGPT.exe / chrome.dll file version: 150.0.7871.101
• Windows 10 Enterprise x64, build 19041.1415
• NVIDIA GeForce RTX 3090, driver 577.00

Native crash signature

A Windows x64 minidump confirms that the desktop main process crashed (not a renderer or GPU child process):

• Faulting thread: CrBrowserMain
• Exception: 0xC0000005 read access violation
• Faulting module/RVA: chrome.dll+0x02EC6E66
• RCX = 0
• Faulting instruction: mov rax, qword ptr [rcx+0x558]
• Read address: 0x558
• WinDbg bucket: NULL_CLASS_PTR_READ_c0000005_chrome.dll!GetHandleVerifier
• Failure hash: {c519d649-9c8b-047c-3153-6d1cd407b31b}

Private Chromium symbols for this build are unavailable, so GetHandleVerifier appears to be only the nearest exported symbol. The module RVA and faulting instruction are the reliable identifiers.

Sanitized Browser Use correlation

Local timestamps are HKT / UTC+8:

• 19:47:43.971 — IAB backend info request failed: No ChatGPT browser route is available
• 19:47:53.945 — a hidden-browser-use webview was created with initialUrl=about:blank
• 19:47:54.004 — mcp_app_sandbox.attach_unmatched, url=undefined
• 19:47:54.349 — last main-process log: browser sidebar reached DOM-ready on a localhost page
• 19:53:34 — the access violation was captured

There is about a 5 minute 40 second gap between the last app-log entry and the captured exception. Browser Use was active and the lifecycle resembles this report, but I am treating that as correlation rather than claiming the localhost navigation was the immediate cause. The exact final UI gesture has not yet been isolated.

Two dump files were captured 13 seconds apart from the same PID, thread, registers, and exception address; they are a small minidump and a full-memory snapshot of one crash, not two separate reproductions.

• Small minidump: 323,153 bytes; SHA-256 dda594922fcdca8fd3413b899ae92cb6b1ca85d8833797cdc6dd766982f0eb9d
• Full-memory dump: approximately 1.18 GiB

I am not attaching either dump publicly because even minidumps can contain stack memory and local metadata, while the full-memory dump may contain account or conversation data. I can provide the 323 KB minidump through a private OpenAI channel if a maintainer requests it.

Adding another independent Windows reproduction that matches this issue.

Environment

• Codex Desktop MSIX: 26.707.3748.0
• Internal Electron/Sentry release: codex@26.707.31428
• Windows 11 Pro x64, version/build 10.0.26200
• NVIDIA GeForce RTX 4070 Ti, driver 32.0.15.9636

Minimal reproduction

The target was a plain local React/Next.js dashboard served over HTTP. Before the final reproduction, both the page and its JSON data endpoint returned HTTP 200.

The final Browser Use operation was only:

const tab = await browser.tabs.new();
await tab.goto("http://localhost:3000/");
await tab.title();
await tab.url();

No media, canvas, WebCodecs, upload, or page interaction was involved. Immediately afterward, the Codex desktop app closed and had to be reopened. The localhost server, which was running as a Codex terminal child process, was also terminated with the app process tree.

Repeated timestamp correlation

Local timestamps are America/New_York / UTC-4:

| Last Codex/browser log | AppModel-Runtime event 217 |
|---|---|
| 08:39:48 | AppX container destroyed at 08:39:50 |
| 08:42:19 | AppX container destroyed at 08:42:21 |
| 08:45:15 | AppX container destroyed at 08:45:18 |
| 09:20:58 | AppX container destroyed at 09:21:00 |

Each run used a different Codex process. The browser-related helper and the main Codex app-server both stopped logging at the failure boundary.

Negative diagnostics

For these reproductions I found:

• No matching Windows Application Error or WER 1000/1001/1002 record
• No Reliability Monitor crash record
• No Codex Crashpad report or dump
• No Sentry exception
• No terminal panic in the structured Codex log database

Windows only recorded destruction of the full Codex AppX container, followed by a later manual activation with a new process ID.

This supports the observation that the in-app Browser lifecycle can terminate the current Windows build even for a basic localhost React page, without a WER/Crashpad artifact. I have not attached the full structured log database because it contains local thread and tool-call metadata, but I can provide narrowly sanitized rows if a maintainer requests them.

Adding another independent Windows reproduction that closely matches this issue, with one potentially useful variant: these three exits did not end with Failed to upsert Browser Use PiP content. Instead, each desktop process ended at or immediately after the hidden IAB webview attach/createTab/debugger-listener lifecycle.

Environment

• Codex Desktop MSIX: 26.707.3748.0
• Bundled Browser release: 26.707.31428
• Windows 11 x64, OS build: 10.0.26200
• NVIDIA GeForce RTX 5090
• Backend: built-in Codex Browser (iab), not the Chrome extension
• Several Codex tasks were active; one task was using built-in Browser Use

Three repeated silent exits

Local time zone: Europe/Istanbul (UTC+3).

| Local AppX destruction | Last desktop log | AppModel event |
|---|---|---|
| 12:32:10 | 09:32:08.418Z | Event 217, Record 104757 |
| 14:36:13 | 11:36:13.392Z | Event 217, Record 104783 |
| 17:04:06 | 14:04:05.525Z | Event 217, Record 104817 |

No power loss, Windows restart, or manual Codex exit occurred for these three incidents.

The repeated Browser lifecycle boundary was:

renderer created browser sidebar webview
  hostKind=hidden-browser-use initialUrl=about:blank
mcp_app_sandbox.attach_unmatched
  url=undefined urlProtocol=invalid
runtime attached browser sidebar webview
iab createTab mapped page to tab
registered debugger listener

The affected sessions also contain No ChatGPT browser route is available for browser session and conversation-state routing errors. In each case the desktop log then stopped without a clean shutdown marker, and Windows destroyed the Codex AppX container approximately 1–3 seconds later.

Negative diagnostics

For these three exits I found no matching:

• Windows Application Error, Application Hang, or WER 1000/1001/1002 event
• Codex Crashpad report or local crash dump
• Chromium render-process-gone or GPU-process crash
• NVIDIA nvlddmkm/TDR or WHEA hardware event
• terminal fatal exception or clean Codex shutdown

This appears consistent with a related non-PiP path through the IAB route/session/webview ownership lifecycle. Concurrent tasks or thread switching may make the race easier to trigger, but I am treating that as a hypothesis rather than claiming a confirmed root cause.

Sanitized evidence with the three lifecycle tails and negative checks is attached below. Conversation/thread/browser IDs, usernames, workspace paths, prompts, URLs, and page contents have been removed. Full raw logs are intentionally not public.

codex-browser-hidden-webview-repro-sanitized.txt

I think I am hitting the same or a closely related issue.

In my case, the Codex Windows app crashes when using the internal @Browser tool to open any URL. It is not limited to localhost.

Reproduction:

1. Open Codex for Windows.
2. Start a new thread.
3. Ask: Use @Browser to open https://example.com.
4. Codex connects to the internal browser.
5. As soon as it tries to open the URL, the whole Codex app closes instantly.

Also reproduced with:

• http://127.0.0.1:5173/ running a Vite app
• http://localhost:5173/
• http://127.0.0.1:5174/ running a minimal local Node HTTP server
• https://example.com

Environment:

• Codex version: 26.707.31428
• Release date shown in About: July 10, 2026
• Installed from: Microsoft Store
• OS: Windows 10 Pro 22H2
• OS build: 19045.6466
• WebView2 Runtime: installed during troubleshooting, version 150.0.4078.48

Troubleshooting already tried:

• Restarted Codex.
• Reinstalled Codex from Microsoft Store.
• Disabled AVG Behavior Shield temporarily; the crash still happened.
• Confirmed the local Vite app works in Chrome.
• Confirmed the crash is not specific to localhost by testing https://example.com.
• Tested a minimal local Node HTTP server on 127.0.0.1:5174; Codex still crashed.
• Checked Windows Event Viewer; no obvious new application error was shown when Codex closed.
• codex-computer-use.exe exists in the Codex runtime folder.
• The app closes instantly with no error dialog.

This started immediately after updating Codex.

This may also be related to #32094, but my case is broader because @Browser crashes the whole app with any navigation, including https://example.com.

Follow-up to my earlier data point in this comment: I now have a much tighter file:// reproduction on the same Windows machine.

Environment

• Codex Desktop MSIX: 26.707.3748.0
• Bundled Browser release: 26.707.31428
• Codex app-server: 0.144.0-alpha.4
• Windows 11 Pro x64, build 10.0.26200
• NVIDIA GeForce RTX 5090, Windows driver version 32.0.16.1074
• Backend: right-panel built-in Browser / IAB, not the Chrome extension

Minimal local page

The trigger was a generated local image gallery opened from a normal Markdown file link in a completed Codex task:

file:///C:/Users/<redacted>/Desktop/<redacted>/artifacts/image_batches/pilot-001/gallery/index.html

The gallery itself is intentionally simple:

• index.html: 3,415 bytes
• static HTML/CSS only
• no JavaScript, event handlers, network requests, external resources, base64, or data URLs
• nine relative local PNG references
• each PNG validates as 1254 x 1254, 24-bit RGB
• all PNGs total 13,614,965 bytes (about 12.98 MiB compressed; about 54 MiB decoded)

The associated parent rollout was only 11.39 MiB. The complete task tree, including 11 child-agent rollouts, was 48.59 MiB. This is therefore not the previously reported 500+ MiB image-history / V8 string-length failure mode.

Four repeated silent exits

Codex logs use UTC. Local time was Europe/Istanbul / UTC+3.

| Attempt | Browser webview created | dom-ready on the local gallery | Final desktop log | Next Codex launch |
|---|---:|---:|---:|---:|
| 1 | 21:50:04.639Z | 21:50:05.124Z | 21:50:05.947Z | 21:50:10.836Z |
| 2 | 21:50:46.969Z | 21:50:47.453Z | 21:50:48.014Z | 21:50:54.984Z |
| 3 | 21:51:16.068Z | 21:51:16.405Z | 21:51:17.371Z | 21:51:20.166Z |
| 4 | 21:53:10.355Z | 21:53:10.681Z | 21:53:11.275Z | 21:53:26.968Z |

Sequence:

1. The first click opened the gallery in the right-panel Browser.
2. The page rendered successfully and reached dom-ready.
3. The desktop log ended abruptly without a normal shutdown record.
4. After Codex was manually relaunched, the Browser sidebar restored the same file:// tab.
5. The restored tab reproduced the same silent full-app exit three more times.

Each attempt included this warning shortly before the successful webview attachment:

mcp_app_sandbox.attach_unmatched guestWebContentsId=3 url=undefined urlProtocol=invalid

I am not claiming that warning is the root cause because similar attach warnings can occur during otherwise successful temporary about: attachment flows. The stronger invariant is: right-panel webview creation -> runtime attachment -> gallery dom-ready -> abrupt end of the main desktop log.

Negative evidence

Across the four exits I found:

• no final Failed to upsert Browser Use PiP content record in this reproduction
• no Recoverable Chromium child process gone / processType=GPU record
• no Application Error 1000, WER 1001, AppHang 1002, .NET Runtime, GPU/Display/TDR, WHEA, or resource-exhaustion event
• no new Crashpad report, Local CrashDump, or WER dump
• no backend panic or clean desktop shutdown record

This makes it another silent main-app exit variant, rather than evidence for the explicit GPU-child signature in #32094.

Why this may help narrow the issue

This reproduction indicates that neither Browser Use automation nor a complex localhost application is required. A user click on a small, script-free file:// page is enough, and restoring the same Browser tab after restart reproduces the exit. It closely overlaps #30558 and the WebContents attach/navigation path in #30178.

The practical workaround remains to avoid the in-app Browser and open the gallery in external Chrome. I can provide sanitized log tails with the exact lifecycle records if a maintainer requests them; I am withholding raw logs because they contain local paths and thread metadata.

I can independently reproduce what appears to be the same Browser Use route/session failure on a different Windows version, using the same Codex Desktop build.

Environment

• Codex / ChatGPT Windows desktop package: OpenAI.Codex_26.707.3748.0_x64
• Browser plugin release reported by local logs: 26.707.31428
• Chrome plugin release: 26.707.31428
• Embedded Browser Use Node runtime: v24.14.0
• OS: Windows 10 Enterprise x64, 10.0.19045
• Workspace: local Godot project on a secondary drive

Reproduction and observed behavior

The browser runtime bootstraps and reports the IAB backend as available. Navigation then fails consistently:

1. Initialize the bundled Browser skill and select the IAB backend.
2. Create/reuse a tab.
3. Navigate to https://xgaida.itch.io/bloodlines-ui and request a DOM snapshot.
4. The Browser Use tool call ends as aborted.
5. Reconnect and repeat: the second call also ends as aborted.

I then tried the bundled Chrome backend:

• https://help.openai.com/ — browser-control execution timed out and the JS tool session reset.
• https://openai.com/form/codex-project-showcase-and-feedback/ — timed out and reset.
• Retrying the feedback form — timed out and reset again.

Overall: 5/5 Browser Use navigation attempts failed. The desktop host stayed open in this case, but each affected browser-control execution was aborted or reset.

Network/control comparison

This does not appear to be ordinary DNS or network failure:

• The itch.io page, purchase flow, official download URL generation, and asset files were all accessible from the same task and machine using PowerShell Invoke-WebRequest.
• Godot MCP, GitHub connector, terminal commands, and filesystem operations remained healthy.
• No CAPTCHA, login page, permission prompt, or safety interstitial appeared before the failures.

Matching local log evidence

At 2026-07-11T04:10:12.973Z, the Codex desktop log records:

warning [browser-use-iab-api] IAB_LIFECYCLE iab backend info request failed
errorMessage="No ChatGPT browser route is available for browser session ..."
request=getInfo

The surrounding log confirms that:

• the IAB backend startup completed;
• the native Browser Use pipe was listening;
• the Node runtime status was ok;
• a browser sidebar webview was subsequently created and attached;
• the task-facing Browser Use operation still aborted.

This looks consistent with a race or stale mapping between the Browser Use session, ChatGPT browser route, sidebar webview attachment, and the Node/browser client. The first getInfo sees no route, the route is recreated immediately afterward, and the client may continue with a stale page/tab binding or wait on an event belonging to the replaced route.

Additional value compared with the original report

• Reproduces on Windows 10 build 19045, not only Windows 11.
• Reproduces with public HTTPS pages, not only localhost.
• Reproduces through both IAB and the bundled Chrome backend, with different failure surfaces (aborted vs timeout/reset).
• Same Codex desktop build and same key route error.

I have a longer sanitized report and can provide selected log excerpts if useful. I have intentionally not uploaded the full desktop log because it contains local paths and task/thread metadata.

I can corroborate this issue on Codex Desktop for Windows, release 26.707.31428.

The main Codex app exited twice while opening a loopback-hosted local page in the in-app Browser. The failure reproduced during the browser sidebar webview attachment sequence.

In both runs, the last relevant lifecycle sequence included:

mcp_app_sandbox.attach_unmatched
url=undefined
urlProtocol=invalid

The webview subsequently reported dom-ready, and the Codex desktop log then ended without a normal shutdown record. A new Codex process appeared after each exit.

The browser tab also appeared to be registered under a temporary client-new-thread route while its owner route pointed to an existing thread, suggesting a possible browser-tab/session routing race during webview attachment.

The local page successfully reached dom-ready, and no ordinary application error or crash dump was generated. I am intentionally not attaching full logs because they contain local workspace and thread metadata.

Additional confirmed reproduction from another affected Windows installation (2026-07-11, Asia/Bangkok, UTC+7).

Environment:

• Codex Desktop 26.707.3748.0
• Bundled Browser plugin 26.707.31428
• Windows 11 Pro x64, build 10.0.26200
• Chromium/Electron file version 150.0.7871.101
• NVIDIA RTX 4070 Ti, driver 32.0.15.9186

This installation has now exited at least six times today while the in-app Browser path was involved: approximately 08:12, 08:44, 12:25, 15:01, 21:07, and 21:43 local time. The latest reproduction was especially direct: the user manually clicked to open Browser inside Codex, and Codex closed immediately.

The repeated final lifecycle in the desktop logs is:

1. IAB_LIFECYCLE registers/opens the browser sidebar.
2. A webview is created with initialUrl=about:blank.
3. mcp_app_sandbox.attach_unmatched ... url=undefined urlProtocol=invalid.
4. The runtime attaches the webview.
5. browser sidebar dom-ready ... url=about:blank (on some runs it reaches http://localhost:5173/).
6. The desktop log stops and the AppX container is destroyed 1–2 seconds later; Codex restarts.

No fresh Crashpad dump, native WER crash entry, OOM event, GPU reset, or Defender detection was found for these exits.

There is also a workaround/persistence issue: setting

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

did not remain effective after restart. Bundled plugin marketplace sync later re-added Browser and rewrote the setting to enabled = true, allowing another crash. A skill-level disable plus a global instruction to never use IAB is currently required as an emergency mitigation.

Expected:

• A failed or unmatched IAB/webview attachment must not terminate the desktop host.
• Disabling the bundled Browser plugin must persist across marketplace refresh/restart.

No full logs or local workspace/thread paths are included because they contain private metadata. Sanitized excerpts can be provided if maintainers request them.

Confirmed on the same Codex Desktop build, 26.707.3748.0, Windows x64 build
10.0.26200.

I observed the same failure three times. In every occurrence, the final two desktop log events were Browser Use PiP metadata followed immediately by:

[browser-use-pip] Failed to upsert Browser Use PiP content backend=iab tabID=1

Additional evidence: in all three runs, the browserID in the immediately preceding PiP metadata event appears truncated or malformed:

• -ca95-4794-ad0b-6f45fd4385c7
• -7e3e-41c1-971a-3bac88bffae9
• -9a75-4483-8711-91f4b27b9229

Each value appears to be missing the first UUID segment.

The affected Browser Use thread also logged:

No ChatGPT browser route is available for browser session <redacted>

The tab was successfully created and navigated to a localhost page before the PiP failure. The desktop log stopped immediately after the upsert warning and Codex exited without a crash dialog.

Unlike the original report, I did not find a corresponding WER/Application Hang event or Crashpad dump.

The original crash occurred during an already-active extensive task. Restarting Codex and resuming the task were recovery actions, not the original trigger.
The same Browser Use operation then caused the crash again after recovery.

Avoiding Browser Use, the in-app browser, and PiP prevents the observed failure. I have complete logs from all three occurrences and can provide them privately to OpenAI Support.

Additional reproduction from Windows 11, with some lifecycle/plugin-state evidence that may help narrow the failure.

Environment

• Codex Microsoft Store package: OpenAI.Codex_26.707.3748.0_x64
• Browser/Chrome plugin release: 26.707.31428
• Browser extension version observed: 8.1.0.9425
• Embedded Node runtime: v24.14.0
• OS: Windows 11 Home x64, 10.0.26200
• Browser backend: iab

Reproduction

The failure reproduced 3/3 times while opening a healthy local HTTP preview through Browser Use, at 08:50:40Z, 08:54:12Z, and 09:04:15Z on 2026-07-12.

In all three runs:

1. The IAB webview attached successfully.
2. The page reached dom-ready.
3. The Browser Use tool returned successfully; the rollout recorded no disconnect, timeout, or failed tool status.
4. The final two lines of the Codex main-process log were:

info [browser-use-pip] Received Browser Use PiP metadata backend=iab tabID=1
warning [browser-use-pip] Failed to upsert Browser Use PiP content backend=iab tabID=1

The log then ended abruptly, with no normal cause=stop_process record. New Codex processes started at 08:52:08Z, 08:54:39Z, and 09:04:34Z respectively.

Additional lifecycle observations

During the 09:04:34Z restart, bundled plugin reconciliation oscillated within one launch:

bundled_plugin_uninstall_requested pluginName=browser reason=not_in_bundled_marketplace_plugin_names
bundled_plugin_install_requested pluginName=browser reason=missing
bundled_plugin_install_requested pluginName=browser reason=outdated
bundled_plugin_install_requested pluginName=chrome reason=outdated

The Chrome native host was stopped/replaced during that sequence. The browser profile also acquired four sequential directories for the same extension version (8.1.0.9425_0 through _3) at approximately 08:50:41Z, 08:54:13Z, 09:04:16Z, and 09:07:46Z, immediately around the affected runs.

On the final recovered process, 09:07:44.856Z through 09:07:45.460Z contained 29 IAB_LIFECYCLE ... rebound browser sidebar window records and 22 repeated warnings:

failed to load browser sidebar comment mode site status
errorMessage="Sign in to ChatGPT to load browser site status."

That burst was followed by mcp_app_sandbox.attach_unmatched ... urlProtocol=invalid, successful webview attach/dom-ready, and another abrupt end of the main log.

The IAB native pipe, Node runtime, and REPL all reported healthy/ready before these exits. No matching Codex Application Error/WER event, Crashpad dump, exception code, or faulting module was present.

The plugin/profile churn, auth-warning burst, and PiP warning are correlated observations, not a proven root cause. The PiP warning may still be the last observable symptom rather than the crashing operation.

I am not attaching the raw rollout or unredacted desktop logs because they contain full task content, local paths, and internal identifiers. Sanitized excerpts can be provided if maintainers request a specific section.

I can reproduce this on Windows with Codex Desktop 26.707.3748.0.

Repro:

1. Start Codex Desktop on Windows.
2. Open/control the in-app browser to https://www.google.com/.
3. The page loads briefly, then the whole Codex app exits.
4. Reopening Codex starts a new ChatGPT.exe process set.

Observed from a watcher started before triggering the repro:

• Existing ChatGPT.exe processes disappeared at 2026-07-12T20:56:16.5765599+07:00.
• The latest relevant Codex log before exit shows the in-app browser webview attach and navigation succeeded:
• browser sidebar dom-ready ... url=https://www.google.com/
• [browser-use-pip] Received Browser Use PiP metadata backend=iab ... tabID=1
• [browser-use-pip] Failed to upsert Browser Use PiP content backend=iab tabID=1
• No Windows Application Error event was recorded for the exit in this repro.
• No ChatGPT.exe / Codex .dmp appeared under %LOCALAPPDATA%\CrashDumps.

This reproduces with a public website, not just localhost. I have a local diagnostic zip with process snapshots and Codex log tails if maintainers want a sanitized excerpt.

The issue still exists in ChatGPT 26.707.51957. It is a blocker issue - browser is completely nonfunctional, any page opened closes ChatGPT.

Independent reproduction with matching Browser Use route/PiP sequence

I appear to have an independent reproduction of the same Windows in-app Browser failure.

My matching Codex desktop logs show:

1. A Browser Use route was initially associated with the permanent conversation ID.
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 Browser Use webview.
2. http://localhost:3000/ reached DOM-ready.
3. The logs then reported:

Failed to upsert Browser Use PiP content

1. The entire Codex desktop app terminated approximately one second later.

The matching Crashpad dump shows:

• Codex App: 26.707.8168.0
• Chromium: 150.0.7871.115
• Crashing thread: CrBrowserMain
• Exception: 0xC0000005
• Fault: chrome.dll+0x2e08f46
• RCX: 0x0
• Invalid read address: 0x558

I posted the fuller dump and environment summary here:

https://github.com/openai/codex/issues/30178#issuecomment-4955536444

The exact matching native crash signature is also documented in #32683.

The issue still exists in ChatGPT 26.707.62119. Released 13 jul 2026

Confirming that this remains reproducible on the newer Codex Desktop build 26.707.8479.0.

Environment:

• Codex Desktop MSIX: OpenAI.Codex_26.707.8479.0_x64
• Windows x64, OS build 10.0.26200
• Backend: built-in in-app Browser / IAB

Minimal reproduction:

1. Initialize the in-app Browser.
2. Create a new tab with browser.tabs.new().
3. The Browser loading UI appears briefly at about:blank.
4. The entire Codex Desktop app exits and relaunches.

Reproduction rate: 2/2. No navigation or page DOM-ready event is required.

Windows AppModel-Runtime evidence:

• 2026-07-14 00:13:54 Europe/Berlin — Event ID 217 destroyed the Desktop AppX container.
• 2026-07-14 00:13:59 — a new container and Codex process were created.
• An earlier reproduction produced another Event ID 217 at 2026-07-13 23:56:24.
• No matching Windows Application Error event was found in the inspected period.

Feedback ID:

019f5d77-ac40-73d1-a522-0413b937d35d

This was initially reported as #32885; closing that report as a duplicate of this issue.

Follow-up with a controlled old-profile vs fresh-profile A/B test. This produced a stable workaround and narrows the failure to inconsistent embedded Chromium profile/update state.

Environment

• Codex Desktop MSIX: 26.707.8479.0
• Bundled Browser release: 26.707.62119
• Chromium: 150.0.7871.115
• Windows 11 x64: 10.0.26200
• Backend: built-in in-app Browser (iab)
• Local time zone for timestamps below: Europe/Berlin (UTC+2)

How we found it

1. We correlated the abrupt end of each desktop log with Windows AppModel-Runtime/Admin Event 217 (full Codex AppX container destruction). The minimal trigger was only: create an IAB tab, navigate to about:blank, wait. No application page or Browser Use automation was required.
2. We then inspected the embedded Chromium profile and noticed that each affected Browser open created another directory for the same extension version:

• 23:46:03: 5.6.5_2 created -> Event 217 at 23:46:05
• 23:56:22: 5.6.5_3 created -> Event 217 at 23:56:24
• 00:13:51: 5.6.5_4 created -> Event 217 at 00:13:54
• 00:38:56: 5.6.5_5 created during the minimal about:blank baseline -> Event 217 at 00:38:57

1. The extension ID is fjoaledfpmneenckfbpdfhkmimnjocfa; its manifest identifies it as VPN for Chrome: NordVPN proxy protection, version 5.6.5.
2. That extension ID was not present in the currently scanned ordinary Chrome, Edge, or Brave user profiles; the repeated state was isolated to Codex's embedded Chromium profile.
3. The affected partition's Secure Preferences had not been updated since July 9 and still referenced:

fjoaledfpmneenckfbpdfhkmimnjocfa\5.6.4_0
even though the filesystem contained 5.6.5_0 through 5.6.5_5. This looks like an extension update/profile commit that repeatedly unpacks the new version but never commits the new path before the app exits.

1. With Codex stopped, we reversibly renamed the embedded profile (%APPDATA%\Codex\web\Codex) to a timestamped backup and let Codex create a fresh profile.
2. We repeated the exact same minimal test on the fresh profile:

• create IAB tab
• navigate to about:blank
• wait more than five seconds
• navigate to https://example.com/
• verify domcontentloaded and the Example Domain title

The fresh-profile run stayed alive and loaded the page successfully. No new AppModel Event 217 was recorded after the test.

Important discriminator

The fresh profile automatically installed the same NordVPN 5.6.5 extension as 5.6.5_0, but this time Secure Preferences was updated immediately to 5.6.5_0, and Codex remained stable. Therefore the presence of NordVPN alone is not sufficient to reproduce the crash. The stronger discriminator is the stale/inconsistent extension update state in the old embedded profile.

The fresh IAB session also still returned a malformed-looking Browser ID with a leading hyphen, yet it did not crash. That ID shape is therefore not sufficient by itself either.

One Event 217 at 00:44:02 was deliberately induced while stopping Codex to release the profile lock for the A/B test and should be excluded from the natural-crash count.

Current conclusion / workaround

This A/B result points to Chromium profile recovery or extension-update handling during IAB startup. A safe workaround is to fully close Codex, rename %APPDATA%\Codex\web\Codex as a backup, and relaunch so a clean embedded Browser profile is created. This may reset embedded-browser sessions, so renaming is preferable to deleting.

I am not claiming the extension is the root cause; the evidence points more specifically to how Codex/Chromium handles a stale, partially committed extension-update state during Browser webview startup.

Independent 2/2 reproduction on 26.707.8479.0; previously implicated extension is absent

Adding another independent reproduction that matches this issue, with an additional profile-state discriminator.

Environment

• Codex Desktop MSIX: OpenAI.Codex_26.707.8479.0_x64
• Windows 11 Pro for Workstations Insider Preview, x64, build 10.0.26220
• Bundled Chromium: 150.0.7871.115
• Bundled Browser release observed in logs: 26.707.62119
• Local time zone: Asia/Shanghai

Exact reproduction timeline

The same operation was attempted twice. Each tool call created a new in-app Browser tab and then requested navigation to an external HTTPS URL.

First reproduction:

• 09:11:52.026 - Browser call issued: browser.tabs.new() followed by tab.goto(...)
• 09:11:53.346 - mcp_app_sandbox.attach_unmatched guestWebContentsId=3 url=undefined urlProtocol=invalid
• 09:11:53.431 - browser sidebar reached DOM-ready at about:blank
• 09:11:56.811 - AppModel-Runtime/Admin Event 217 destroyed the Codex Desktop AppX container
• 09:12:03.654 - Codex was launched again

Second reproduction after relaunch:

• 09:13:17.774 - the same Browser call was issued again
• 09:13:18.176 - the same attach_unmatched warning
• 09:13:18.272 - browser sidebar reached DOM-ready at about:blank
• 09:13:21.691 - Event 217 destroyed the AppX container
• 09:13:27.180 - Codex was launched again

Reproduction rate: 2/2.

The target HTTPS page never reached a logged DOM-ready state. Because tabs.new() and goto() were issued in one tool call, this evidence narrows the failure to tab/WebView creation or very early navigation, but does not claim which individual API call causes the native termination.

Before the first exit, Browser Use also logged:

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

The Browser sidebar route was associated with a temporary client-new-thread identifier while the tool request belonged to the permanent conversation ID. IDs are omitted here because they are not needed to reproduce the issue.

Negative diagnostics

For both exits:

• no Windows Application Error or Application Hang event
• no WER app-crash record
• no Crashpad report
• no resource-exhaustion event
• no Microsoft Defender event involving Codex
• no Codex fatal, panic, graceful quit, or shutdown marker before the logs stopped

Embedded profile discriminator

I checked the active Codex embedded Chromium profile without modifying it:

• extension ID fjoaledfpmneenckfbpdfhkmimnjocfa (the NordVPN extension discussed in a previous comment) is absent
• Secure Preferences contains no reference to that extension ID
• each installed extension has only one version directory; there is no repeated _1, _2, etc. unpack pattern

No profile reset or extension cleanup was attempted before these reproductions.

This shows that the stale/inconsistent NordVPN extension-update state described in the fresh-profile A/B workaround is not required for the crash on 26.707.8479.0. The broader IAB/WebView lifecycle or Chromium main-process path still appears to be affected.

Full local logs are not attached because they contain local paths and conversation metadata. Sanitized excerpts can be provided if maintainers request them.

@ITGitM Thank you — this is important negative evidence and a useful correction to the scope of my A/B result.

I agree that your reproduction shows the stale NordVPN extension-update state is not required for this crash. The profile reset should therefore be treated as a local mitigation that worked on my machine, not as a universal fix or the underlying root cause.

After reading your result, I reran the same regression test on my currently cleaned profile:

• Codex Desktop: 26.707.8479.0
• create a new IAB tab
• keep about:blank open for 5 seconds
• navigate to https://example.com/ and verify DOM/content
• keep the loaded page open for another 10 seconds

The app remained alive, no new AppModel Event 217 appeared during the following 10-minute window, and the embedded profile still contains only 5.6.5_0 with no duplicate extension directories.

So the local profile-state A/B remains repeatable here, but your clean-profile 2/2 failure demonstrates that it cannot explain the broader issue. Across both machines, the stronger shared signals are now the Browser route/session mismatch and the WebView lifecycle around attach_unmatched / about:blank DOM-ready immediately before the native app termination.

Thanks for checking the profile state specifically — that materially narrows what maintainers should treat as a general cause versus a machine-local trigger.

Adding an independent Windows reproduction from a local Vite game project.

Environment

• Codex Desktop MSIX: OpenAI.Codex_26.707.9564.0_x64
• Windows x64, OS version 10.0.26200
• Local app: Vite 7.3.6, TypeScript, Canvas + DOM UI
• URL: http://127.0.0.1:5173/

Reproduction

1. Start the project with npm run dev.
2. Open the local game in Microsoft Edge and interact with it; it runs normally.
3. Open the same URL through Codex Desktop's built-in Browser / Browser Use.
4. Codex Desktop unexpectedly exits/crashes, requiring the app to be restarted.

Expected

The embedded browser should load the localhost game without terminating the Codex host. A browser/webview failure should remain isolated from the main app.

Workaround

The project now explicitly prohibits opening the game in the Codex built-in Browser. Testing is done in Microsoft Edge or an external headless browser instead.

This comparison is useful because the same server and application operate normally in Edge; the failure appears specific to the Codex embedded browser path. No full logs are attached because they may include local workspace and thread metadata.

Additional corroboration from a separate Windows 10 22H2 x64 setup:

• Codex Desktop Beta package: 26.707.3351.0. The embedded Browser runtime configuration reported 26.707.30751.
• Repro: open the in-app Browser / IAB backend to a simple local static HTTP page on 127.0.0.1. The control channel successfully returns the page title and DOM, then the visible Codex desktop app silently restarts.
• This rules out the target page being unavailable: navigation and DOM access complete before the host dies.
• Clearing only the embedded Browser session state and fully relaunching Codex did not help. A fresh post-reset attempt reproduced the same restart.
• No Playwright/headless-shell process was active and no Playwright environment overrides were set at the time of the repro.

Sanitized messages observed around the failure:

No ChatGPT browser route is available for browser session
mcp_app_sandbox.attach_unmatched ... urlProtocol=invalid
Failed to upsert Browser Use PiP content backend=iab tabID=1

There was also a repeated chat-process notification JSON parse warning caused by an unexpected NUL character.

The user first noticed the problem after installing Playwright 1.57.0's Chromium headless shell, but the checks above do not establish Playwright as the cause; it is only a reported timing correlation.

Expected: a Browser/IAB or PiP attachment failure should be isolated to the browser surface and leave the main Codex task usable. Actual: the full desktop host restarts shortly after a simple localhost page is attached.

I can reproduce a closely related silent restart on a newer Windows Store build.

Environment

• Codex AppX: OpenAI.Codex_26.707.9981.0 x64
• Windows 11 x64
• Local time zone: Asia/Shanghai (logs are UTC)

Observed incident (2026-07-15, local time about 00:29)

1. 00:29:07: the desktop log began emitting rapid repeated failures:

``text
No ChatGPT browser route is available for browser session ...
`
followed by repeated getInfo` calls against the same stale session.

1. 00:29:10: the browser sidebar/guest was torn down and webcontents-destroyed was logged.
2. 00:29:11: Windows AppModel-Runtime recorded the Codex AppX container being destroyed.
3. 00:29:15: Codex automatically relaunched.
4. The new session again logged browser-route-loss errors around 00:31.

The coding task continued, but the visible Codex desktop UI silently closed/restarted. There was no corresponding Windows Application Error, WER APPCRASH, or Crashpad dump, so this looks like a container/host restart rather than a conventional crash.

This happened repeatedly over roughly four to five days (three visible incidents). The common correlation is Codex's in-app Browser / Browser Use lifecycle, specifically stale IAB route retries followed by sidebar teardown.

I am intentionally not attaching raw logs because they include local paths, task metadata, and conversation identifiers. I can provide further sanitized lifecycle lines or targeted diagnostics through a private channel if maintainers request them.

Current workaround: avoid the Codex in-app Browser after a route-loss event; use external Chrome, API, or CLI for browser/data work, and do not keep retrying the invalid browser session.

Platform: Windows 11, Codex Desktop 26.707.72221

Independent confirmation of the same Browser Use PiP failure. Adding a variant that may help narrow the race condition:

My desktop log shows:

No ChatGPT browser route is available for browser session …
Received Browser Use PiP metadata … tabID=undefined
Failed to upsert Browser Use PiP content

Note tabID=undefined rather than the tabID=1 seen in most other reports. The PiP metadata arrived before any tab ID was assigned to the webview, suggesting the Browser Use PiP upsert is racing against the IAB tab lifecycle — the upsert fires before the webview/tab is fully initialised.

The process ended without a clean shutdown ~24s later and auto-restarted. No crash event in Windows Application logs and no minidump generated — the exit may be an abrupt Chromium termination that WER doesn't capture.

The bundled Chromium version is 150.0.7871.115 (same as reported elsewhere). See also #32683 for the native crash signature (CrBrowserMain null-pointer read in chrome.dll) which likely shares the same root cause.

Summary

The Codex Windows desktop app repeatedly freezes/closes and then relaunches. This is happening several times within a short period, including while using a normal conversation.

Environment

• OS: Windows 11 Home
• OS build: 26100.8737
• Codex app package: OpenAI.Codex
• Codex app version: 26.707.9981.0
• Architecture: x64
• Agent environment: Windows native / PowerShell
• Approximate RAM: 16 GB

Observed behavior

Windows AppModel lifecycle events show repeated destruction and recreation of the entire Codex application container:

• 4:55:52 PM — application container destroyed
• 4:57:11 PM — application launched
• 5:00:11 PM — application container destroyed
• 5:02:02 PM — application launched
• 5:05:24 PM — application container destroyed
• 5:09:29 PM — application launched
• 5:16:03 PM — application container destroyed
• 5:16:09 PM — application launched

The app disappears/freezes and comes back after several seconds. All ChatGPT.exe and codex.exe processes receive new start times after each incident, confirming that the whole application is restarting rather than only a conversation failing.

There is no standard Windows Application Error event or Crashpad dump for these recent restarts. Windows records them as controlled AppX container shutdowns.

Earlier related crash

An earlier Codex build also produced a native crash:

• Version: 26.707.3748.0
• Faulting process/module: codex.exe
• Exception code: 0xc0000409
• Exception parameter/data: 7
• Windows event: Application Error 1000
• Timestamp: July 13, 2026 at 4:08:26 PM
• WER event type: MoBEX / fatal application exit

The app subsequently updated to 26.707.9981.0, but the repeated shutdown/relaunch behavior continues.

Expected behavior

The desktop app should remain open and the current task should continue without the entire application restarting.

Reproduction

1. Open the Codex Windows desktop app.
2. Open or continue a normal task.
3. Use the task for several minutes.
4. The application freezes or disappears.
5. The complete application relaunches shortly afterward.

The issue occurred repeatedly within approximately 20 minutes.

Additional information

Immediately after relaunch, all processes report as responding. Combined memory usage is approximately 1.2–1.3 GB. No recent Codex files appear in the Crashpad directory, and Windows Reliability Monitor does not show a conventional application crash for the latest incidents.

Codex feedback session ID: 019f6279-351a-7ff3-8c4a-adb77fb4f7b9

Adding another fully controlled reproduction on Windows 10. This also matches the route-mismatch symptoms reported in #33332.

Environment:

• Windows 10 Pro 22H2 x64, build 19045
• Codex Store package: 26.707.9981.0
• Browser plugin release: 26.707.72221
• GPU: NVIDIA RTX 4070 SUPER, driver 32.0.15.9174

Minimal reproduction:

1. Launch Codex Desktop.
2. Initialize the in-app Browser.
3. Open a fresh tab and navigate to https://example.com/.
4. Browser control successfully returns “Example Domain” and the correct URL.
5. The complete Codex AppX container exits immediately afterward and Codex restarts with a new PID.

Relevant sanitized log messages:

• “No ChatGPT browser route is available for browser session <redacted>”
• “mcp_app_sandbox.attach_unmatched ... urlProtocol=invalid”
• The Browser webview reaches dom-ready for https://example.com/ before the host exits.

Windows AppModel-Runtime records destruction of the Codex AppX container. There is no corresponding Application Error, WER APPCRASH, Crashpad report, GPU reset, Display/nvlddmkm event, or WHEA error.

Clean-profile test:
I fully exited Codex and moved Local Storage, Session Storage, Preferences, Cache, Code Cache, GPUCache, Dawn/Graphite caches, and shader caches to a backup. The reset moved 12 items with 0 failures. Codex then reinstalled/refreshed the bundled Browser plugin.

The first post-reset attempt reproduced the same exit after example.com loaded successfully. This makes stale profile data, browser cache, plugin cache, localhost behavior, and a hardware/GPU failure unlikely.

Expected behavior:
A route-binding or PiP failure should return a recoverable Browser error without terminating the Codex Desktop host.

Raw logs are not attached because they contain local paths and task/session identifiers. Sanitized excerpts can be provided if requested.

Additional reproduction on Windows 10 Pro 22H2 (10.0.19045), Codex Desktop 26.707.9981.0.

The crash/restart reproduced three consecutive times while Browser Use opened http://127.0.0.1:4173/ for visual QA. The Vite site stayed healthy and returned HTTP 200; only Codex Desktop exited. A full PC restart did not resolve it.

Sanitized log evidence immediately around the failures:

[BrowserUseThreadConfig] ... bundled cua_node ... node.exe --version ...
nodeVersionError={code:3221225794,killed:false,signal:null}
[AppServerConnection] fatal_error_broadcasted ... code=3221225794
[browser-use-pip] Failed to upsert Browser Use PiP content backend=iab tabID=1

There is also an unrelated-looking plugin sync warning in the same startup window:

failed to download remote installed plugin bundle ... plugin.json name ... does not match marketplace plugin name `canva`

Observed result: the main Codex window closes and must be reopened; the Browser Use tool call is reported as aborted. Workaround confirmed: avoid the in-app browser and run headless Playwright from the terminal.

No full log attached because it contains local paths/thread metadata, but the relevant desktop logs are timestamped 2026-07-16 around 03:32-03:38 UTC.

Update — confirmed fixed in the latest build (July 17, 2026).

I updated the Codex Desktop App to the latest Microsoft Store version today and tested the in-app browser with multiple sites:

• OpenAI.com: loaded and rendered normally ✅
• GitHub.com: loaded and rendered normally ✅

Codex remained responsive with 9 active processes throughout. Windows Event Viewer recorded 0 new ChatGPT.exe crash events.

The fix appears to have shipped silently through the Store auto-update mechanism — no changelog entry, but the crash that reproduced consistently on versions 26.707.3748.0 through 26.707.9981.0 is no longer occurring on this machine.

Closing this issue. Anyone still experiencing the crash should ensure they're on the latest Store build and re-open if it persists.

Verified fixed on latest build — see comment above for test results.