›_ Codex Issues
Codex Issues / #32683

[Windows] Codex App crashes in CrBrowserMain when Browser Use opens a page (0xC0000005 at chrome.dll+0x2e08f46)

Open 💬 25 comments Opened Jul 13, 2026 by udxklsj
💡 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.8168.0

What subscription do you have?

ChatGPT Pro (20x)

What platform is your computer?

Microsoft Windows NT 10.0.22631.0 x64

What issue are you seeing?

On Windows, asking Codex to use its in-app browser / Browser Use IAB backend reliably crashes the entire Codex App. There is no error dialog; the application simply disappears.

A neutral page is sufficient to reproduce it. The exact prompt used was:

请用内置浏览器打开 example.com

English translation: Please use the in-app browser to open example.com.

The page reaches DOM ready, then the browser process crashes about 1–5 seconds later.

I captured six Crashpad minidumps from independent reproductions. All six have the same native crash signature and the same Chrome stack prefix:

Process type: browser
Crashing thread: CrBrowserMain
Exception: 0xC0000005 (EXCEPTION_ACCESS_VIOLATION)
Operation: read
Invalid address: 0x558
Fault: chrome.dll+0x2e08f46
RCX: 0x0
Instruction: mov rax, qword ptr [rcx+0x558]
Chromium version: 150.0.7871.115

This is a null-object read in the Chromium browser main thread, not a renderer-only failure or a normal app exit.

The app log consistently reaches the Browser Use IAB WebView attach/navigation path immediately before the crash. A representative redacted sequence is:

IAB_LIFECYCLE renderer created browser sidebar webview ... initialUrl=about:blank
mcp_app_sandbox.attach_unmatched guestWebContentsId=3 url=undefined urlProtocol=invalid
IAB_LIFECYCLE runtime attached browser sidebar webview ...
IAB_LIFECYCLE registered debugger listener ...
browser sidebar dom-ready ... url=https://example.com/

Some reproductions also contain this immediately before the crash, although it is not present in every reproduction:

Received Browser Use PiP metadata ... tabID=1
Failed to upsert Browser Use PiP content ... tabID=1

What steps can reproduce the bug?

  1. Start Codex App on Windows.
  2. Open either a new conversation or an existing saved conversation.
  3. Send this prompt:

``text
请用内置浏览器打开 example.com
``

  1. Wait for the in-app browser WebView to open and navigate to https://example.com/.
  2. Within approximately 1–5 seconds after DOM ready, the entire Codex App exits without an error dialog.

Observed reproduction rate during diagnosis: 6/6.

Affected Codex session/thread ID from the final reproduction:

[REDACTED — available privately to OpenAI maintainers upon request]

Token/context usage is not a factor: this also reproduces in a fresh, nearly empty conversation.

What is the expected behavior?

The in-app browser should open https://example.com/ and remain usable without terminating the Codex App.

If Browser Use or the WebView fails, Codex should report a recoverable error and keep the main application running instead of crashing the Chromium browser process.

Additional information

Controlled tests already performed

  • Reproduces with both a new conversation and an existing saved conversation.
  • Reproduces with both https://example.com/ and a Discord page, so it is not specific to one website.
  • Reproduces with both a visible right-panel WebView and a hidden Browser Use host.
  • A targeted Chromium-partition reset was attempted, but later inspection showed that the active nested Chromium profile retained older files. Therefore, I am not claiming this as a verified clean-profile reproduction.
  • Reproduces with Nahimic stopped. The resulting dump contained no Nahimic/A-Volute modules but had the identical crash address and Chrome stack.
  • Reproduces with Windhawk stopped. The resulting dump contained no Windhawk modules/plugins but had the identical crash address and Chrome stack.
  • Reproduced on app package 26.707.6957.0 and again after updating to 26.707.8168.0. Both packages used Chromium 150.0.7871.115 and produced the same native fault.

Excluded system-level causes

  • No Windows Display, nvlddmkm, WHEA, DxgKrnl, or GPU-reset events occurred around the crashes.
  • The GPU child process remained alive until the browser main process terminated.
  • No out-of-memory or resource-exhaustion event was recorded. One representative incident had about 65% committed memory in use, about 3.2 GB available physical memory, and low page-file utilization.
  • The main process was responsive immediately before the crash; this is not an AppHang.

Existing issue search

I searched the repository for Windows crashes involving Browser Use, chrome.dll, and CrBrowserMain.

  • #24998 is broadly related because the Windows app closes unexpectedly, but it does not identify Browser Use/IAB as the trigger or report this fixed CrBrowserMain / chrome.dll+0x2e08f46 signature.
  • #21530 and #21912 concern Browser Use/IAB discovery or connection failures rather than a reproducible native browser-main crash.

This therefore appears to be a distinct, reliably reproducible Browser Use/IAB native crash.

Diagnostic artifacts

Crashpad minidumps and full desktop logs are available. I have not attached the raw dumps publicly because minidumps can contain process memory and session data, but I can provide them privately to OpenAI maintainers if requested.

View original on GitHub ↗

25 Comments

github-actions[bot] contributor · 8 days ago

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

  • #32334
  • #32399
  • #32438

Powered by Codex Action

OceanWhiskey98 · 7 days ago

Independent reproduction with matching crash signature and additional route/PiP evidence

I can independently reproduce this issue on Windows with the same Codex App build and native crash signature.

Environment
  • Codex App: 26.707.8168.0
  • Previously reproduced on: 26.707.6957.0
  • Chromium: 150.0.7871.115
  • Platform: Windows x64
  • Trigger: Browser Use opening a localhost page during a repository audit
Observed behavior

The in-app Browser Use flow opens the target page, the page reaches DOM-ready, and the entire Codex App silently exits without an error dialog.

Windows records:

AppModel-Runtime Event ID 217
Destroyed Desktop AppX container for OpenAI.Codex

Native crash signature

The matching Crashpad dump shows:

Process: ChatGPT.exe / Codex App package
Process type: browser
Crashing thread: CrBrowserMain
Exception: 0xC0000005 (EXCEPTION_ACCESS_VIOLATION)
Operation: read
Invalid address: 0x558
Fault: chrome.dll+0x2e08f46
RCX: 0x0
Instruction: mov rax, qword ptr [rcx+0x558]
Chromium version: 150.0.7871.115

This matches the signature described in this issue.

Additional log sequence

My matching desktop logs also show a Browser Use conversation-route problem before the native crash:

  1. A Browser Use route is initially associated with the permanent conversation ID.
  2. The route is then reassigned to a temporary client-new-thread identifier.
  3. Browser Use later reports:

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

  1. Codex creates a replacement hidden Browser Use WebView.
  2. The target http://localhost:3000/ page reaches DOM-ready.
  3. The logs then report:

Failed to upsert Browser Use PiP content

  1. The application terminates approximately one second later with the matching chrome.dll access violation.

I am not claiming the route reassignment or PiP failure is the proven root cause, but they are repeatable precursors in my captured logs.

Troubleshooting already attempted
  • Updated Codex from 26.707.6957.0 to 26.707.8168.0
  • Rebuilt/reset the Browser plugin cache
  • Recreated and restored the local Codex profile
  • Started a fresh task
  • Reproduced during a repository audit rather than only a dedicated browser test

The fault persisted across both app package versions, which used the same Chromium build.

Diagnostic artifacts

I have the matching:

  • Crashpad minidump
  • t0, t1, and t4 desktop logs
  • AppModel-Runtime Event 217 screenshot
  • Affected session information

I have not attached the raw dump or full logs publicly because they may contain local paths, session identifiers, project details, or process-memory fragments. I can provide them privately to OpenAI maintainers upon request.

Related detailed comment:

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

Enigfrank · 7 days ago

Independent reproduction on Windows 10; full Chromium profile reset restored Browser Use

I independently reproduced this issue with the same Codex App version, but without a generated Crashpad minidump.

Environment
  • Codex App: 26.707.8168.0
  • Platform: Microsoft Windows NT 10.0.19045.0 x64
  • Chromium: 150.0.7871.115
  • Trigger URL: https://example.com/
Observed behavior

Opening https://example.com/ through the Codex in-app Browser caused the entire Codex App to silently exit.

The desktop log reached:

IAB_LIFECYCLE renderer created browser sidebar webview
mcp_app_sandbox.attach_unmatched guestWebContentsId=2 url=undefined urlProtocol=invalid
IAB_LIFECYCLE registered debugger listener
browser sidebar dom-ready ... url=https://example.com/

The log then ended abruptly. The main Codex process disappeared and Windows recorded:

Microsoft-Windows-AppModel-Runtime
Event ID 217
Destroyed Desktop AppX container for OpenAI.Codex

There was no Windows Application Error event and no .dmp file. The Codex Crashpad directory contained only settings.dat.

Earlier runs also contained:

No ChatGPT browser route is available for browser session ...
IAB_LIFECYCLE route window is not live
IAB_LIFECYCLE removed browser session window

The active Chromium profile reported:

profile.exit_type = Crashed
Additional version-state observation

Before the crash, the bundled Browser client cache used version:

26.707.51957

while the IAB backend reported:

release=26.707.61608

After restarting Codex, the Browser plugin cache was automatically refreshed to 26.707.61608.

I am not claiming this version difference as the proven root cause, but it may be relevant.

Workaround that restored Browser Use

With Codex completely closed, I renamed the full embedded Chromium profile:

%APPDATA%\Codex\web\Codex

to a timestamped backup directory, then restarted Codex so it generated a new profile.

Verification after the reset

Using the same Codex App version:

  1. Browser Use opened https://example.com/ successfully.
  2. The returned page title was Example Domain.
  3. A second independent browser call successfully read the page DOM.
  4. The Codex main process remained alive with the same PID.
  5. The Browser Use tab closed normally afterward.

Therefore, a complete reset of %APPDATA%\Codex\web\Codex is a confirmed workaround in this environment.

Because both the Chromium profile and Browser plugin version changed before the successful retest, I cannot conclusively isolate which state caused the original crash.

thepurplemongoose · 7 days ago

Confirming the same failure on a newer Windows build.

Environment:

  • Codex App package: 26.707.8479.0
  • Bundled Chromium / chrome.dll: 150.0.7871.115
  • Affected task/session: 019f58ac-a385-7fa0-ab68-6a91bb703830

I observed four separate Codex process lifetimes ending abruptly immediately after Browser Use navigated an IAB webview to an ordinary HTTPS login page. Representative final sequence:

IAB_LIFECYCLE registered debugger listener ...
browser sidebar dom-ready ... url=https://[redacted]/login
<desktop log ends; entire app disappears>

Other matching signals before some reproductions:

No ChatGPT browser route is available for browser session ...
mcp_app_sandbox.attach_unmatched guestWebContentsId=... url=undefined urlProtocol=invalid

The affected process/log windows ended at approximately 13:20:21Z, 14:24:35Z, and 14:33:39Z on 2026-07-13; the latest reproduction occurred after updating from app 26.707.3748.0 to 26.707.8479.0. The newest build still carries Chromium 150.0.7871.115.

I found:

  • no Windows Application Error or AppHang event for these exits
  • no Windows resource-exhaustion event
  • no Crashpad report under either Codex Crashpad reports directory
  • no evidence the target website itself was at fault

Avoiding the in-app Browser stops the process exits. This appears to match the native CrBrowserMain failure reported here, including the Chromium version and DOM-ready timing.

TalentGroGlobal · 7 days ago

Independent reproduction on 26.707.3748.0 with bundled-plugin reconciliation evidence

I independently reproduced this failure three consecutive times on Windows.

Environment

  • Codex desktop package 26.707.3748.0 (Microsoft Store)
  • Windows 11 Pro x64, build 26100
  • Intel Core i5-11400F, 15.9 GB RAM
  • NVIDIA GT 1030, driver 32.0.15.8228
  • Bundled Browser plugin cache observed at 26.707.31428

Repeated failure signature

Each short-lived desktop instance exited immediately after the same in-app Browser (IAB) lifecycle:

mcp_app_sandbox.attach_unmatched
runtime attached to hidden IAB webview
browser sidebar dom-ready: about:blank
registered debugger listener
<log ends; app container is destroyed>

This occurred for three separate process instances. Windows AppModel event 217 then recorded destruction of the application container. I found no matching Windows Error Reporting, Application Error, Application Hang, resource-exhaustion event, or Crashpad report.

As a control, after avoiding the in-app Browser, a fresh Codex instance remained stable for more than 31 minutes without an AppX destruction event or dump. Codex Doctor reported installation, configuration, authentication, network, WebSocket, and database checks as healthy; its only warning was TERM=dumb from the non-interactive diagnostic shell.

Additional bundled-plugin reconciliation evidence

I also attempted a controlled disabled-state test:

  1. Configuration successfully wrote plugins."browser@openai-bundled".enabled=false.
  2. On restart, startup logs initially showed five runtime marketplace plugins, excluding Browser.
  3. Logs then recorded bundled_plugin_uninstall_requested for Browser and successful removal.
  4. External plugin synchronisation/reconciliation started.
  5. The marketplace was rewritten with six plugins, including Browser.
  6. Logs recorded bundled_plugin_install_requested because Browser was missing/outdated, followed by successful installation.
  7. Configuration returned to Browser enabled.

That repeatable reconciliation behaviour prevented a clean A/B test with the bundled Browser disabled.

This corroborates the Browser Use crash reported here and adds evidence that bundled-plugin reconciliation can automatically reinstall/re-enable Browser, defeating the normal disable workaround. I am not claiming that reconciliation is the native crash root cause; it is a separate repeatable behaviour relevant to isolating and mitigating the crash.

I have retained sanitised event timelines, Doctor output, and redacted log excerpts. Raw configuration, authentication data, tokens, usernames, local paths, and task/session identifiers are excluded.

Ritsukid · 7 days ago

Confirming on a newer Codex App build

This issue still reproduces on a newer package than those reported above.

Environment

  • Codex App package: 26.707.9564.0
  • Platform: Windows 10 Pro x64, build 19045
  • Bundled Chromium / chrome.dll: 150.0.7871.115

Observed behavior

Opening the in-app Browser preview reliably causes the entire Codex App to exit silently. The embedded Chromium profile currently reports:

profile.exit_type = Crashed

I found no fresh Windows Application Error/AppHang event and no new Crashpad dump for these exits. Avoiding the in-app Browser keeps the app usable.

This confirms that the failure remains present in app package 26.707.9564.0, which is newer than 26.707.8479.0 and 26.707.8168.0 reported earlier in this thread.

No raw logs or profile files are attached because they contain private local paths and session metadata.

DasMonkey · 6 days ago

adding a similar crash report:

Title

Windows Codex Desktop 26.707.9981.0 crashes immediately when creating an in-app Browser tab

Codex version

OpenAI Codex Desktop (Microsoft Store/MSIX): 26.707.9981.0

Platform

  • Windows x64
  • Windows build: 10.0.26200
  • Embedded Chromium: 150.0.7871.115

Problem

After the latest Codex Desktop update, starting an in-app Browser tab causes the entire Codex application to terminate and relaunch.

This is not caused by the local development server. The server was already running, remained healthy, and returned HTTP 200 throughout the incident.

The crash happens while creating an empty about:blank Browser tab, before Codex navigates to the localhost URL.

Steps to reproduce

  1. Open Codex Desktop on Windows.
  2. Open a coding task with a local web project.
  3. Ask Codex to perform rendered frontend QA using the in-app Browser.
  4. Allow the Browser integration to initialize.
  5. Codex calls browser.tabs.new().
  6. The Browser briefly begins creating an about:blank tab.
  7. The entire Codex Desktop application exits without an error dialog.
  8. Codex relaunches several seconds later.

Reproduction rate in this task: 2/2.

Expected result

Codex should create the Browser tab and remain running.

If Browser initialization fails, the failure should be recoverable and should not terminate the desktop application or interrupt the active tool call.

Actual result

The complete Codex AppX container is destroyed. After Codex relaunches, the interrupted task contains missing tool-call state.

Codex then repeatedly logs an error similar to:

Custom tool call output is missing for call id

That error appears to be a consequence of Codex terminating while the Browser tool call is still active.

Local diagnostic timeline

First controlled reproduction:

  • 2026-07-14 23:31:39 — Codex dispatched browser.tabs.new().
  • 2026-07-14 23:31:42 — Windows AppModel-Runtime Event ID 217 destroyed the Codex Desktop AppX container.
  • 2026-07-14 23:31:51–23:31:52 — Windows created a new AppX container and relaunched Codex.

Second reproduction:

  • 2026-07-14 23:38:50 — Windows AppModel-Runtime Event ID 217 destroyed the Codex AppX container again.
  • 2026-07-14 23:38:56 — Windows relaunched Codex.

Windows also recorded:

  • Event: RADAR_PRE_LEAK_64
  • Process: ChatGPT.exe
  • Process version: 150.0.7871.115

The installed Codex package was:

OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0

Development-server checks

The Vite development server was already listening at:

http://127.0.0.1:5173

It continued returning:

  • HTTP status: 200
  • Correct StoryTime HTML title
  • Running Node process remained alive

Codex crashed before navigating the Browser tab to this URL. Therefore, the Vite server and port were not the crash source.

Affected thread

Codex thread ID:

019f60cd-2a4a-7d40-aa98-917f8c5ae491

Suspected cause

This appears to be the same Windows 26.707 embedded Chromium / in-app Browser regression reported here:

In this reproduction, even creating an empty about:blank tab is sufficient to terminate the Codex AppX container. No website navigation, authentication, or application JavaScript is required.

Workaround

Avoiding the Codex in-app Browser prevents this specific crash. Shell commands, TypeScript builds, Vite, Cargo, and the local development server continue working normally.

Raw Codex SQLite logs and session files are available privately if requested. I have not attached them publicly because they may contain prompts, local paths, command history, and tool output.

win000st · 6 days ago

Independent reproduction on 26.707.9981.0: blank tab is sufficient

I independently reproduced the Windows in-app Browser crash on the current Microsoft Store/MSIX build.

Environment

  • Codex Desktop: OpenAI.Codex_26.707.9981.0
  • Platform: Windows x64
  • Time zone for timestamps below: Asia/Hong_Kong
  • Backend: built-in in-app Browser / IAB

Minimal reproduction

  1. Select the Codex in-app Browser.
  2. Call tabs.new().
  3. The call returns a valid blank tab: { id: "1", url: "about:blank", title: "about:blank" }.
  4. The complete Codex app exits immediately afterward.

No website navigation, page JavaScript, authentication, localhost server, or page DOM content is required.

Repeated evidence

Three app sessions ended at approximately 09:53:21, 22:27:06, and 22:45:29 on 2026-07-14 immediately after opening an IAB tab.

Every failing session contained:

  • multiple No ChatGPT browser route is available for browser session ... warnings;
  • one mcp_app_sandbox.attach_unmatched ... url=undefined urlProtocol=invalid warning;
  • final lifecycle events at iab createTab mapped page to tab and/or browser sidebar dom-ready;
  • no normal app-server shutdown sequence.

A separate clean session contained zero route failures and zero unmatched webview attachments, and ended normally with stop_process / disconnected.

The Browser Crashpad report database changed about two seconds after the controlled crash, but no retained .dmp was available. No matching Windows Application/WER crash event was found.

This corroborates the existing 26.707.9981.0 report and narrows the trigger to IAB guest-webview creation/attachment itself. The route warnings are a repeatable precursor, but I am not claiming they are the proven native root cause. Full local logs and the affected Codex session ID can be provided privately if an OpenAI maintainer requests them.

travelingparents · 6 days ago

Additional independent reproduction: cross-thread, localhost and about:blank

I independently reproduced the same Windows IAB crash across multiple Codex tasks on 2026-07-13 and 2026-07-14.

Environment

  • Codex AppX package currently registered: 26.707.6957.0
  • Browser/IAB release in desktop logs: 26.707.51957
  • Chromium profile version: 150.0.7871.115
  • Windows 11 Home x64, build 26200

Two distinct triggers with the same result

  1. A visible right-panel webview was created with initialUrl=http://127.0.0.1:8765.
  2. In a different task after restarting Codex, Browser Use created a hidden webview with initialUrl=about:blank.

Both runs then recorded:

mcp_app_sandbox.attach_unmatched guestWebContentsId=<n> url=undefined urlProtocol=invalid
IAB_LIFECYCLE did attach browser sidebar webview

The desktop log ended immediately afterward and Windows destroyed/relaunched the Codex AppX container. The same attach_unmatched sequence occurred the previous day in another task, followed by debugger-listener registration and an abrupt log end.

Earlier in the same sessions, the IAB client repeatedly reported:

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

This establishes that the failure is not specific to localhost, the development server, page JavaScript, or one conversation. An empty about:blank host is sufficient, and it reproduces across tasks.

Crash artifacts

  • Embedded Chromium profile reports exit_type = Crashed.
  • No fresh Crashpad dump was retained; only settings.dat changed.
  • No matching Windows Application Error was recorded.
  • No GPU reset/display-driver event coincided with the exits.
  • Raw logs are not attached publicly because they contain local paths and task/session identifiers; sanitized excerpts can be provided privately.

Update-state observation

Windows repeatedly staged OpenAI.Codex_26.707.9981.0 successfully, but after a full exit/relaunch Get-AppxPackage OpenAI.Codex still reported 26.707.6957.0. This may be unrelated to the native crash, but it complicated verifying the newer package locally. Other comments already confirm that 26.707.9981.0 remains affected.

alexgogan · 6 days ago

Additional controlled Windows reproduction.

Codex package:
OpenAI.Codex 26.707.9981.0

Feedback ID:
no-active-thread-019f61e2-8be2-78f1-b7d9-4cb56a99ae0f

Probe thread:
019f618e-aa2b-75d0-9107-b292f20cae88

Reproduction:

  1. Created a new disposable thread.
  2. Confirmed it remained stable for tool-free and local-terminal turns.
  3. Asked the built-in Browser to open https://example.com.
  4. example.com reached DOM-ready.
  5. Approximately two seconds later, the entire OpenAI.Codex process tree terminated, including the desktop processes and codex.exe.

Process watcher:
18:04:33 local — process count increased from 8 to 9.
18:04:35 local — process count dropped to 0.

Probe transcript size:
0.55 MB

Relevant final desktop-log sequence:

  • No ChatGPT browser route is available for browser session
  • browser route associated with client-new-thread:...
  • mcp_app_sandbox.attach_unmatched
  • example.com DOM-ready
  • Received Browser Use PiP metadata
  • Failed to upsert Browser Use PiP content
  • desktop log then stopped

The transcript, watcher CSV, package logs, Windows events, and SHA-256 manifest are preserved locally. I excluded current session logs and browser-tab data from the in-app feedback submission for privacy, but sanitized evidence can be provided privately to an OpenAI maintainer if requested.

GlaucoPassalacqua · 6 days ago

Confirmed on a newer Windows build with the same signature.

Environment

  • Codex Desktop package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
  • Platform: Windows x64
  • Local timezone: Europe/Rome
  • Trigger: Codex autonomously invoked Browser Use while inspecting https://www.amicidipassi.it/; the user did not manually open an in-app browser.

Reproduction

Observed twice on 2026-07-14 (2/2):

  1. At ~21:04 local time, Codex created/attached the hidden Browser Use webview and navigated to the public page. The whole Codex/ChatGPT process group disappeared within seconds.
  2. After relaunch, the same Browser Use action reproduced the failure at ~21:19. The final relevant desktop log sequence was:
IAB_LIFECYCLE renderer created browser sidebar webview ... hostKind=hidden-browser-use initialUrl=about:blank
IAB_LIFECYCLE runtime attached browser sidebar webview ...
IAB_LIFECYCLE registered debugger listener ...
browser sidebar dom-ready ... url=https://www.amicidipassi.it/
Received Browser Use PiP metadata ... tabID=1
Failed to upsert Browser Use PiP content backend=iab tabID=1

The desktop log stops immediately after that final warning.

An independent process monitor sampled all ChatGPT/Codex processes as present at 21:19:34 and absent at 21:19:40. Free physical memory was approximately 1.4 GB immediately before termination and rose afterward, so this did not look like demonstrated system-wide memory exhaustion.

Crash artifacts checked

No matching artifact was found in:

  • Windows Application/System error events
  • Windows Error Reporting
  • %LOCALAPPDATA%\CrashDumps
  • Codex Crashpad reports

This closely matches the reported Browser Use / Chromium main-process termination behavior. The current workaround is to avoid the in-app Browser entirely and use an external/headless browser or command-line HTTP tooling. Sanitized log excerpts can be provided if useful.

lindaNNT · 6 days ago

Confirmed on a newer Codex Desktop build with a localhost page.

Environment

  • Codex Desktop MSIX: 26.707.9981.0
  • Bundled Browser plugin/runtime: 26.707.72221
  • Windows 11 Home x64, build 10.0.26200
  • Native Windows/PowerShell workspace (not WSL)
  • IAB target: an ASP.NET Core development host at https://localhost:7148/

Reproduction

Reproduced 2/2 times:

  1. Start the local HTTPS development host.
  2. Ask Codex to open/inspect it with the built-in Browser (IAB).
  3. The browser sidebar attaches and reports DOM ready.
  4. About 1-2 seconds later, the complete Codex window/process disappears without an error dialog.
  5. Restart Codex and resume the interrupted task.
  6. Repeat, with the same result.

First reproduction ended immediately after:

2026-07-14T20:24:00.561Z info [browser-sidebar-manager] browser sidebar dom-ready ... interactionMode=browse url=https://localhost:7148/
2026-07-14T20:24:02.241Z info [browser-session-registry] IAB_LIFECYCLE rebound browser sidebar window ...

The restarted app reproduced it again:

2026-07-14T20:25:14.474Z warning [mcp-app-sandbox] mcp_app_sandbox.attach_unmatched guestWebContentsId=3 url=undefined urlProtocol=invalid
2026-07-14T20:25:15.955Z warning [browser-sidebar-manager] failed to sync browser page color scheme errorMessage="Timed out syncing browser page color scheme" webContentsId=3
2026-07-14T20:25:16.599Z info [browser-sidebar-manager] browser sidebar dom-ready ... interactionMode=browse url=https://localhost:7148/

The desktop log then stops abruptly at 20:25:18.160Z, with no graceful shutdown record.

The same startup also reconciled the bundled Browser plugin, first requesting an uninstall with reason=not_in_bundled_marketplace_plugin_names, then reinstalling it with reason=missing. This may be incidental, but it occurred in the same short window as the IAB attachment.

Additional observations

  • No matching Windows Application Error/Application Hang event was recorded.
  • No Crashpad minidump was created for these two reproductions, so I cannot independently confirm the exact chrome.dll address reported in this issue.
  • The local HTTPS application remained healthy and the same authentication/cookie/protected-route flow succeeded outside IAB.
  • The Codex app had new process start times after reopening, confirming a full app restart rather than only a closed browser tab.
  • Current workaround: avoid IAB and use external Playwright/API smoke checks.

Raw logs are not attached publicly because they include local paths and conversation metadata, but sanitized excerpts can be provided if useful.

YwYAI · 6 days ago

Additional matching reproduction on Codex Desktop 26.707.9981.0

I encountered what appears to be the same failure on a newer Codex Desktop build.

Environment
  • Codex Desktop: 26.707.9981.0
  • OS: Windows 11 Pro for Workstations, build 26200, x64
  • CPU: Intel Xeon W-2235
  • RAM: 31.69 GB
  • GPU: NVIDIA Quadro P600
  • GPU driver: 32.0.15.7344
Observed behavior

While Codex was using the in-app browser/browser sidebar to inspect a local HTML tutorial, the entire desktop application exited without an error dialog. A new Codex instance was started manually approximately 100 seconds later.

The local file:// navigation had already been blocked by policy before the page's JavaScript could execute, so the inspected page code did not run. The final desktop log sequence was in the IAB/WebView lifecycle:

No ChatGPT browser route is available for browser session
IAB_LIFECYCLE renderer created browser sidebar webview ... initialUrl=about:blank
mcp_app_sandbox.attach_unmatched guestWebContentsId=2 url=undefined urlProtocol=invalid
IAB_LIFECYCLE runtime attached browser sidebar webview ...
browser sidebar dom-ready ...

The log then ended abruptly. This closely matches the attach/navigation sequence reported here and in #30178.

Checks performed
  • No Windows Application Error or WER event was recorded during the incident window.
  • No out-of-memory, render-process-gone, or fatal JavaScript stack was present in the available desktop logs.
  • The host had sufficient RAM; there was no evidence of resource exhaustion.
  • Because the file:// target was blocked before page execution, application JavaScript is unlikely to be the direct trigger.
  • No Crashpad minidump was available for this occurrence, so I cannot confirm whether the native fault address is identical to the one reported here.
Expected behavior

A blocked or failed Browser Use/WebView navigation should return a recoverable error and leave the main Codex application running.

I have retained a sanitized incident report and can provide additional redacted log context if maintainers request it. Raw logs are not posted publicly because they may contain local workspace or session metadata.

2batsloverandomartifactromps-dotcom · 6 days ago

Additional 8-crash sequence, current-build recurrence, and shipped-bundle findings

I have an independent Windows reproduction that matches this issue and adds a correlated eight-crash sequence plus two source-level findings that rule out misleading log signals.

Environment
  • Windows 11 Home x64, build 10.0.26200
  • Current Codex AppX: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
  • Current desktop/browser bundle build: 26.707.72221
  • Bundled Chromium / chrome.dll: 150.0.7871.115
  • Electron declared by the shipped desktop bundle: 42.1.0
  • Bundled app-server: 0.144.2
  • GPUs: NVIDIA RTX 5080 Laptop GPU plus Intel Graphics
Eight confirmed access-violation exits on July 13

A passive Process.Exited tracer recorded eight Codex main-process exits with 0xC0000005. It did not request termination. Every exit followed creation/attachment of an in-app Browser WebView. Seven of the eight logs reached IAB_LIFECYCLE registered debugger listener 1.66–4.02 seconds before the process exit.

| Main PID | Exit time (UTC) | Last debugger-listener event (UTC) | Exit delay |
|---:|---|---|---:|
| 54412 | 12:22:32.885 | 12:22:29.862 | 3.023 s |
| 35488 | 14:07:26.552 | 14:07:23.423 | 3.129 s |
| 4944 | 14:29:35.810 | not logged; WebView attached at 14:29:33.133 | 2.677 s after attach |
| 57396 | 14:32:25.531 | 14:32:21.515 | 4.016 s |
| 62364 | 15:27:37.212 | 15:27:35.550 | 1.662 s |
| 66280 | 15:58:18.510 | 15:58:16.710 | 1.800 s |
| 67328 | 16:01:48.757 | 16:01:46.804 | 1.953 s |
| 12572 | 23:43:59.253 | 23:43:56.275 | 2.978 s |

The final confirmed incident followed this sequence:

23:43:55.503Z Browser Use opens an IAB tab
23:43:56.107Z guest WebView attaches
23:43:56.275Z CDP debugger listener registered
23:43:56.564Z localhost page reaches DOM ready
23:43:59.253Z main process exits with 0xC0000005

The target was a healthy localhost page. Separate pages and tasks produced the same failure.

Current-build recurrence on July 14

After the Microsoft Store update to 26.707.9981.0, post-update inspection found the bundled IAB path enabled again with browser bundle 26.707.72221 and BROWSER_USE_AVAILABLE_BACKENDS="chrome,iab".

The next IAB use produced:

22:30:20.480Z hidden Browser Use WebView created at about:blank
22:30:20.727Z guest WebView attached
22:30:20.946Z CDP debugger listener registered
22:30:21.176Z localhost page reaches DOM ready
22:30:21.400Z Browser Use response metadata received
22:30:23.xxxZ Windows destroys the OpenAI.Codex AppX container

There was no corresponding WER Application Error or Crashpad dump for this recurrence, so I am not claiming a native exception code for the 26.707.9981.0 incident itself. Its lifecycle timing matches the earlier confirmed access-violation exits.

Negative controls and mitigation evidence
  • Four of the confirmed 0xC0000005 processes had been launched with both --disable-gpu and --disable-gpu-compositing; GPU disablement did not prevent the failure.
  • Disabling browser@openai-bundled and restricting Browser Use to the separate Chrome backend stopped the observed crash sequence while leaving Chrome automation available.
  • After the Store/bundle refresh made IAB available again, the crash recurred on the first observed IAB use. Reapplying the IAB block restored stability.
  • No Claude process was changed during this diagnosis.
Two shipped-bundle findings: PiP and truncated browser IDs are red herrings

I inspected the installed app.asar and bundled Browser client read-only.

  1. The desktop PiP upsert implementation returns false on every non-macOS platform. Its caller then logs Failed to upsert Browser Use PiP content. Therefore, that warning is expected on Windows and does not establish PiP as the crash source.
  2. The Browser client deliberately forms its browser ID from a UUID with the first eight characters removed. Values such as -735d-... are therefore expected by the shipped client, not evidence of UUID corruption.

Those findings move the strongest boundary earlier: guest WebContents attachment plus the Electron CDP debugger path. The shipped flow attaches webContents.debugger with protocol 1.3, registers message/destruction/render-process listeners, and then performs browser commands. Seven of eight native exits occurred within four seconds of that boundary, with no render-process-gone recovery log before the browser main process disappeared.

Requested investigation / immediate containment

Please investigate the private Codex/Owl Electron WebView + webContents.debugger lifecycle with symbols for Chromium 150.0.7871.115, especially ownership/finalization during guest attachment, route rebinding, and teardown.

Until the native fault is fixed, please consider remotely disabling IAB on affected Windows builds and falling back to the separate Chrome backend. Also preserve an explicit user IAB disable across bundled-plugin reconciliation or app updates so an update cannot silently restore the crashing path.

Sanitized logs and the correlation table are available. Raw logs are not posted because they contain local paths, thread IDs, task metadata, and conversation content.

win000st · 6 days ago

Update: clean reinstall on the same build restored Browser Use

This is now resolved for me after a clean reinstall of Codex Desktop.

Important detail: Microsoft Store reinstalled the same app build, 26.707.9981.0; this was not fixed by upgrading to a newer version.

Before uninstalling, I backed up %USERPROFILE%\.codex. After uninstalling, I did not restore the old package-local Codex/Browser profile under %LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0.

Controlled retest after reinstall:

  • tabs.new() created an about:blank tab and it remained open for more than 5 seconds;
  • the same in-app Browser tab loaded https://example.com/ successfully;
  • Codex remained running.

This suggests stale or corrupted package-local Browser/app state may be involved. A clean reinstall that resets the package-local profile is a working workaround in my case.

Recommendation for anyone trying this workaround: back up .codex first because it contains sessions/config/auth, and test Browser Use before restoring any old package-local Browser profile. This is one successful clean-profile retest, so I cannot yet rule out recurrence.

wlstn562-gif · 5 days ago

Additional independent reproduction on Windows 10 with Codex App 26.707.9564.0

I can independently reproduce the same DOM-ready → silent full-app exit pattern on a newer Codex App package.

Environment
  • Windows 10 x64, build 10.0.19045
  • Codex AppX: 26.707.9564.0
  • Bundled Browser release observed in local diagnostics: 26.707.71524
  • Bundled Chromium: 150.0.7871.115
  • Trigger: a healthy localhost page opened through the Codex in-app Browser
Sanitized local timeline (KST, UTC+09:00)
11:50:02.691  IAB WebView created for the localhost page
11:50:03.767  browser sidebar reports DOM-ready
11:50:04.621  desktop log ends abruptly without a normal quit sequence
11:50:08      Windows AppModel-Runtime deletes the Codex AppX container
11:50:10      Codex is recreated/restarted

The same page returns HTTP 200 through a non-IAB check and opens normally in external Microsoft Edge. Codex remains alive when the external browser path is used.

There is no local WER Application Error record or Crashpad minidump for this incident, so I am not claiming that this particular reproduction directly proves the CrBrowserMain / 0xC0000005 / chrome.dll+0x2e08f46 signature. The lifecycle timing and unchanged Chromium build strongly match the regression documented in this issue.

Requested fix / containment

Please:

  1. update or patch the bundled Windows IAB/Chromium component rather than only incrementing the outer AppX version;
  2. isolate an IAB/WebView failure so it cannot terminate the main Codex task;
  3. keep an explicit in_app_browser=false (or equivalent external-browser fallback) effective across app/plugin updates;
  4. add a Windows regression canary that covers both normal HTTPS and localhost pages through DOM-ready and several seconds of post-load activity;
  5. publish the first build/browser-component version in which this issue is confirmed fixed.

No raw logs, local paths, thread identifiers, configuration files, or private data are attached.

atiaron · 5 days ago

Additional controlled reproduction on Windows 10 build 19045, Codex App
26.707.9981.0, Chromium 150.0.7871.115: Browser Use tabs.new() alone
created an about:blank IAB tab and the app crashed about two seconds later,
before navigation, page content, DOM inspection, a debugger listener, or
finalization.

The crash signature matches exactly: CrBrowserMain, 0xC0000005 read at
chrome.dll+0x2E08F46, RCX=0, attempted address 0x558.

No raw dump, full logs, local paths, task/session identifiers, project details,
or user data are attached for privacy.

imdoctor-lgtmmuzi · 5 days ago

I can confirm the same Browser Use / IAB crash still reproduces on a newer Windows Store build.

Environment

  • Codex Desktop AppX: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
  • Windows x64, build family 10.0.26200
  • Native Windows workspace (not WSL for the affected thread)

Reproduction

  1. Ask Codex to use the in-app Browser.
  2. Approve the Browser tool invocation.
  3. Codex creates and attaches the browser sidebar WebView.
  4. The entire Codex app silently exits with no error dialog.
  5. Relaunching the app resumes the interrupted conversation.

This reproduced four times in one session. The latest incident occurred on 2026-07-15 around 17:09:53 local time (Asia/Shanghai).

Consistent sanitized log tail

IAB_LIFECYCLE opening route page
IAB_LIFECYCLE created browser sidebar page state
IAB_LIFECYCLE waiting for browser sidebar webview attachment
IAB_LIFECYCLE renderer created browser sidebar webview ... initialUrl=about:blank
IAB_LIFECYCLE browser sidebar will attach webview
warning [mcp-app-sandbox] mcp_app_sandbox.attach_unmatched guestWebContentsId=3 url=undefined urlProtocol=invalid
IAB_LIFECYCLE runtime attached browser sidebar webview
IAB_LIFECYCLE browser use open wait resolved
browser sidebar dom-ready ... url=about:blank

The desktop log then stops abruptly without a normal shutdown sequence. Windows AppModel-Runtime records Event ID 217 destroying the complete OpenAI.Codex_26.707.9981.0 AppX container a few seconds later. There is no matching Application Error / APPCRASH event or user-visible crash dialog.

This is highly consistent with the crash described here and confirms it persists beyond builds 26.707.6957.0 and 26.707.8168.0. The current workaround is to disable browser@openai-bundled and avoid the in-app Browser. Full local logs contain conversation metadata, so only the sanitized sequence is included.

Stormsil · 5 days ago

Independent same-machine A/B: stable 26.707.9981.0 vs installed Beta

I can independently reproduce this on the current Microsoft Store stable package. This report is intentionally sanitized: local usernames, paths, repository names, URLs, thread/request IDs, and raw logs are omitted.

Environment
  • Platform: Windows x64
  • Stable Codex AppX: OpenAI.Codex_26.707.9981.0
  • Stable IAB/Browser release reported in logs: 26.707.72221
  • Embedded Chromium profile version: 150.0.7871.115
  • Installed comparison build: OpenAI.CodexBeta_26.707.3351.0
  • Beta IAB/Browser release: 26.707.30751
Trigger

The failure occurs not only when creating a new Browser tab, but also when opening/resuming a saved coding chat that restores an active Browser Use sidebar tab.

I observed four consecutive stable-app process lifetimes end immediately after Browser Use restored a page. The targets included both a localhost development page and an ordinary HTTPS page, so the target application/site is not required.

Representative sanitized final sequence:

IAB_LIFECYCLE renderer created browser sidebar webview ... initialUrl=about:blank
mcp_app_sandbox.attach_unmatched ... urlProtocol=invalid
IAB_LIFECYCLE runtime attached browser sidebar webview
IAB_LIFECYCLE registered debugger listener
browser sidebar dom-ready ... url=<redacted>
Received Browser Use PiP metadata ... tabID=1
Failed to upsert Browser Use PiP content backend=iab tabID=1
<desktop log ends abruptly>

Windows then recorded:

Microsoft-Windows-AppModel-Runtime/Admin
Event ID 217
Desktop AppX container removed for OpenAI.Codex

There was no normal app-server shutdown, Windows Application Error/AppHang event, WER crash report, or retained Crashpad dump for these exits.

Same-machine working comparison

The separately installed Beta build on the same machine opened and navigated an IAB webview to a localhost application successfully. After the final DOM-ready event, that app instance continued logging normally for more than 14 minutes.

This does not establish that every Beta environment is unaffected. It is a useful same-machine discriminator between:

  • stable app 26.707.9981.0 / IAB 26.707.72221: repeated abrupt AppX termination;
  • Beta app 26.707.3351.0 / IAB 26.707.30751: successful sustained Browser Use in the captured run.

The PiP upsert failure is a repeatable immediate precursor in this environment, but without a dump I am not claiming it is the proven native fault.

Workaround

Avoid restoring or creating in-app Browser tabs in the stable Windows app. The installed Beta build remained usable in the controlled comparison, though external Chrome/Edge is the lower-risk workaround.

Sanitized excerpts and exact UTC timelines can be provided if maintainers need them. Raw logs are not attached because they contain local paths, task metadata, and conversation content.

TheSeriousJ · 5 days ago

Independent Windows reproduction on Intel Arc; exact DOM-ready to silent-exit timeline

I can confirm the same in-app Browser failure on a different GPU configuration.

Environment
  • Codex Desktop AppX at time of reproduction: 26.707.8479.0
  • Current installed AppX: 26.707.9981.0 (not deliberately retested because each reproduction terminates the active desktop session)
  • Windows x64, build 10.0.26200
  • GPU: Intel Arc 140V, driver 32.0.101.8626
  • Additional display device: SuperDisplay Virtual Adapter 3.47.17.59
  • Trigger: manually navigating the right-panel in-app Browser to an ordinary Google search page
Sanitized timeline (UTC, 2026-07-13)
18:40:15.649  renderer created browser sidebar webview; right-panel; Google search URL
18:40:15.824  did attach browser sidebar webview; guest WebContents created
18:40:18.817  browser sidebar DOM-ready for the Google search URL
18:40:19.315  browser sidebar owner/route rebound
<desktop log ends abruptly; no normal shutdown sequence>
18:40:34.xxx  a new Codex desktop process/session begins

The whole Codex window disappeared without an error dialog. The destination worked normally outside the Codex in-app Browser.

Negative evidence
  • No matching Windows Application Error or Application Hang event
  • No matching Windows Error Reporting crash report
  • No Crashpad minidump; only settings.dat
  • No evidence of resource exhaustion

This closely matches the reported IAB/WebView lifecycle and silent full-process termination. It also extends the affected hardware set beyond the NVIDIA configurations already reported here.

I have retained the original logs locally. Raw logs are not posted because they contain local paths, task identifiers, and conversation metadata, but I can provide narrowly sanitized excerpts if an OpenAI maintainer requests them.

BlazingSu · 4 days ago

Independent reproduction on Windows 10 build 19043 / Codex 26.707.9981.0

I can independently reproduce the same silent full-app exit on the current Microsoft Store build.

Environment
  • Codex AppX: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
  • Bundled Browser/IAB release: 26.707.72221
  • Embedded Chromium: 150.0.7871.115
  • Windows 10 Pro x64: 10.0.19043
  • GPU: NVIDIA GeForce GTX 1650
  • NVIDIA driver: 30.0.14.7111 (471.11, 2021-06-21)
Reproduction

The entire Codex process exits shortly after the sidebar WebView attaches and reaches DOM-ready. I reproduced this repeatedly with:

  1. manual sidebar navigation to ordinary HTTPS pages;
  2. Browser Use opening https://example.com/ in the visible IAB panel;
  3. the stable bundled Browser plugin after removing the separately installed beta Browser plugin.

Representative lifecycle:

IAB WebView attached
browser sidebar dom-ready ... url=https://example.com/
<desktop log ends abruptly; entire Codex app disappears>

The failure is not specific to Browser Use automation: manually opened sidebar pages also trigger it. Removing browser@openai-bundled-beta and leaving only the stable bundled Browser did not change the behavior.

Negative evidence / state
  • No matching Windows Application Error, WER, GPU-reset, or resource-exhaustion event.
  • No retained Crashpad minidump.
  • Both embedded Chromium preference stores later reported profile.exit_type = "Crashed".
  • The desktop log has no normal shutdown sequence.
  • The failure occurred across multiple fresh Codex process lifetimes and multiple ordinary sites.

This matches the reported native IAB/Chromium failure boundary. Raw logs are not attached because they contain local paths, task metadata, and conversation identifiers; sanitized excerpts can be provided if maintainers request them.

ChackZz87 · 4 days ago

Still reproducible on Windows 10 with Codex Desktop version 26.707.91948.

The in-app browser itself opens normally and remains stable on about:blank. The crash only occurs after navigating to a website: once the page has finished loading / reaches DOM ready, the entire Codex app silently exits without an error message.

Lx-1-2-3-4 · 4 days ago

Independent reproduction on newer AppX 26.707.12708.0 with full-dump confirmation

I can independently reproduce the identical crash signature on a newer Windows package.

Environment
  • Codex AppX: OpenAI.Codex_26.707.12708.0_x64__2p2nqsd0c76g0
  • Embedded Chromium / chrome.dll: 150.0.7871.115
  • Windows 11 x64, build 26100
Reproduction
  1. Open or restore a task with the visible right-panel in-app Browser.
  2. Open/restore a local file-backed preview.
  3. The WebView attaches and reaches DOM-ready.
  4. The entire Codex app exits about two seconds later without an error dialog.

Representative sanitized lifecycle:

20:35:31.288  renderer created browser sidebar webview; hostKind=right-panel
20:35:31.710  attached browser sidebar guest WebContents
20:35:32.034  browser sidebar DOM-ready
20:35:33.042  ResizeObserver loop completed with undelivered notifications
20:35:33.610  ResizeObserver loop completed with undelivered notifications
20:35:34.xxx  unhandled native crash

The ResizeObserver warnings are correlated precursors in this capture; I am not claiming they are the proven root cause.

Full-dump result

WinDbg analysis of a full process dump shows:

Process: ChatGPT.exe (Codex App)
Crashing thread: CrBrowserMain
Exception: 0xC0000005 (ACCESS_VIOLATION)
Operation: invalid pointer read
RCX: 0x0
Invalid address: 0x558
Fault: chrome.dll+0x2e08f46
Failure bucket: INVALID_POINTER_READ_c0000005_chrome.dll!Unknown

This exactly matches the native signature reported in this issue and confirms that the bug persists in AppX 26.707.12708.0. It also reproduces through a file-backed local preview in the visible right-panel WebView.

The captured module list for the faulting process contained Codex and Windows modules only; no third-party injected modules were observed. Raw dumps and full logs are withheld because they may contain session data, local paths, and process-memory fragments. They can be provided privately to OpenAI maintainers if requested.

Axcyn · 4 days ago

Additional independent reproduction: AppX 26.707.12708.0 crashes on about:blank alone

I independently reproduced the same native crash on 2026-07-16. This reproduction is narrower than page-navigation reports: creating the first controlled IAB tab is sufficient; no real URL is ever loaded.

Environment
  • Codex AppX: OpenAI.Codex_26.707.12708.0_x64__2p2nqsd0c76g0
  • Bundled Browser plugin/runtime: 26.707.91948
  • Embedded Chromium / chrome.dll: 150.0.7871.115
  • Windows 11 Pro x64: 10.0.26200
Minimal reproduction
  1. Fully restart Codex Desktop.
  2. Initialize the bundled Browser runtime and acquire the iab backend.
  3. Run only:

``js
const tab = await iab.tabs.new();
``

  1. The call returns { id: "1", url: "about:blank" }.
  2. Approximately 1.2 seconds after DOM-ready, the entire Codex app exits without an error dialog.

No goto(), website, localhost server, file URL, interaction, subagent, or parallel Browser task is involved. Reproduction rate in this controlled session: 3/3.

Sanitized lifecycle timeline (UTC):

18:17:46.705  renderer created hidden-browser-use webview; initialUrl=about:blank
18:17:46.788  iab createTab mapped page to tab
18:17:46.819  browser sidebar dom-ready; url=about:blank
18:17:48.xxx  unhandled native crash; desktop log ends abruptly
ProcDump-confirmed crash

A Microsoft ProcDump 12.01 unhandled-exception monitor was attached to the main ChatGPT.exe process and produced a 12 MB minidump:

Exception:        0xC0000005 (ACCESS_VIOLATION)
Operation:        READ
Invalid address:  0x0000000000000558
Fault:            chrome.dll+0x2E08F46
RCX:              0x0000000000000000
RIP:              chrome.dll+0x2E08F46
Instruction:      mov rax, qword ptr [rcx+0x558]

The immediate native return sites recovered from the stack/disassembly are:

chrome.dll+0xEC3D893  call chrome.dll+0x2E08F40
chrome.dll+0xEC3D898  return site

chrome.dll+0x8DDABEA  call chrome.dll+0xEC3D860
chrome.dll+0x8DDABEF  return site

chrome.dll+0x9103670  indirect vtable call
chrome.dll+0x9103676  return site

Symbol identity for maintainer-side symbolization:

PDB: chrome.dll.pdb
GUID: 8E0F477B-A59F-319D-4C4C-44205044422E
Age: 1

Dump SHA-256:

1E386CB3BAF8AC8D64B4010F9EBDDA31647B4115FEE764A6B2F50464298942D3

The captured module list did not contain serialport.node, node-hid, or the Work Louder device-kit modules, so this controlled Browser/IAB crash is distinct from the separate 0xC06D007F serialport/device-kit crash reports.

The raw minidump and full desktop log are retained locally and can be provided privately to OpenAI maintainers if requested; they are not attached publicly because they can contain process-memory and session data.

asiamoon25 · 1 day ago

Does this mean the Codex in-app browser isn't supported on Windows 10?