›_ Codex Issues
Codex Issues / #34239

[Windows desktop] Closing in-app Browser tab silently terminates Codex during WebView teardown

Open 💬 4 comments Opened Jul 19, 2026 by Joniverse2
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

Codex Desktop terminated silently while closing the last in-app Browser Use tab. The desktop log ends immediately after the Browser WebView/guest teardown sequence, with no graceful shutdown marker, fatal exception, Windows Error Reporting event, or Crashpad/Sentry report.

The only warning at the failure boundary is:

IAB_LIFECYCLE iab rejected tab for route ... tabId=1 tabRouteKey=null

This is strongly correlated with the termination, but the available evidence does not prove that the warning itself is the root cause.

Environment

  • Codex package: OpenAI.Codex_26.715.4045.0_x64__2p2nqsd0c76g0
  • Codex version: 26.715.4045.0
  • Architecture: x64
  • Windows registry-reported edition: Windows 10 Home Single Language
  • DisplayVersion: 25H2
  • OS build: 26200.8875
  • Time zone: UTC+07:00
  • Affected task/thread ID: 019f7b35-656b-73b0-b239-cac628bfa0b0

Observed sequence

  1. A Codex task used Browser Use against a local frontend while a Node/Vite test server was running.
  2. The focused browser verification completed successfully.
  3. The Browser Use tab was closed.
  4. Codex logged route rejection during teardown with tabRouteKey=null.
  5. The renderer disposed and removed the browser sidebar WebView, and the browser registry closed the page.
  6. The desktop log ended at 2026-07-19T17:35:58.604Z with no shutdown or error record.
  7. Windows destroyed the Codex Desktop AppX container at approximately 2026-07-20 00:36:00.171 +07:00.
  8. The task remained interrupted and produced no final assistant response.

Sanitized failure-boundary log

Codex timestamps below are UTC:

2026-07-19T17:35:58.400Z info [browser-use-iab-api]
IAB_LIFECYCLE unregistered debugger listener ... reason=target-close ... tabId=1 webContentsDestroyed=false webContentsId=3

2026-07-19T17:35:58.402Z info [browser-sidebar-manager]
IAB_LIFECYCLE syncing browser use active state ... isActive=false

2026-07-19T17:35:58.406Z warning [browser-use-iab-api]
IAB_LIFECYCLE iab rejected tab for route ... tabId=1 tabRouteKey=null

2026-07-19T17:35:58.412Z info [browser-use-pip]
Received Browser Use PiP metadata ... tabID=undefined

2026-07-19T17:35:58.544Z info [electron-message-handler]
IAB_LIFECYCLE renderer synced browser use webview state ... isBrowserUseActive=false

2026-07-19T17:35:58.548Z info [electron-message-handler]
IAB_LIFECYCLE renderer disposed browser sidebar webview ...

2026-07-19T17:35:58.563Z warning [browser-session-registry]
IAB_LIFECYCLE browser sidebar guest torn down ... guestWebContentsId=3

2026-07-19T17:35:58.602Z info [electron-message-handler]
IAB_LIFECYCLE renderer removed browser sidebar webview ... tabType=closed

2026-07-19T17:35:58.604Z info [browser-session-registry]
IAB_LIFECYCLE closed browser sidebar page ...

2026-07-19T17:35:58.604Z info [browser-sidebar-manager]
IAB_TAB_ANALYTICS browser tab lifecycle action=closed appBrowserTabCount=0 appBrowserUseTabCount=0 ...
<end of desktop log>

Additional diagnostics

  • No render-process-gone, fatal exception, panic, out-of-memory, or graceful shutdown event was logged at the boundary.
  • No Windows Application Error, Application Hang, .NET Runtime, or WER event was recorded for this occurrence.
  • No System-log reboot, shutdown, display reset, hardware error, or resource-exhaustion event was present around the incident.
  • Crashpad contained no dump for this occurrence.
  • The Sentry queue contained no crash payload.
  • The package status was healthy and there was no package update at the incident time.
  • The local Node/Vite server processes remained alive and continued listening after Codex disappeared, indicating the test server did not terminate the app.
  • The task rollout JSONL ends abruptly at the same boundary and remains marked interrupted.

Expected behavior

Closing a Browser Use tab should cleanly detach and destroy the guest WebContents without terminating Codex Desktop. A route mismatch during teardown should be handled as a recoverable stale-tab condition.

If a renderer or WebView does fail, Codex should:

  • keep the desktop main process alive,
  • preserve/complete the active task as interrupted with a visible recovery state, and
  • emit a diagnostic crash record or recoverable error instead of silently disappearing.

Actual behavior

The entire Codex Desktop app/container terminated immediately after closing the Browser Use tab. There was no crash dialog or actionable diagnostic, and the active task was left interrupted.

Reproduction status

Observed once in this exact form. The temporal correlation is precise, but this report intentionally describes the teardown sequence as the probable trigger rather than claiming a proven faulting module.

Potentially related browser lifecycle reports include #23814, #33514, #33762, and #33827, but those focus mainly on browser creation, navigation, or restoration rather than termination while closing the last Browser Use tab.

Full local logs contain paths and conversation metadata, so only sanitized excerpts are included publicly. Targeted additional evidence can be provided through a private support channel if needed.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 1 month ago

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

  • #33514
  • #33827
  • #33133

Powered by Codex Action

Cataphract450 · 1 month ago

Update 2026-07-29 — native dump and concrete orphan-tab trigger

A new occurrence on the current Windows build produced a full Sentry/Crashpad minidump and exposes a more specific teardown path than the original report.

Environment and native signature

  • MSIX package: OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0
  • Codex / Browser Use release: 26.721.41059
  • Bundled Chromium: 150.0.7871.128
  • Process: main/browser ChatGPT.exe process, not renderer or GPU
  • Exception: 0xC0000005 read access violation
  • Attempted address: 0xFFFFFFFFFFFFFFFF
  • Fault: chrome.dll+0xEC1491E
  • Sentry event ID: 908bf39d18a64ff58ec81dd7363cb7b8
  • Crash time: 2026-07-29 10:53:04 MSK / 07:53:04Z

The crashing thread registers contain common freed/uninitialized-memory poison patterns (RCX=0xEFEFEFEFEFEFEFEF, R11=0xCDCDCDCDCDCDCDCD), consistent with a lifecycle/use-after-free class failure. Private Chromium symbols are not available, so the reliable fingerprint is:

C0000005 / read / FFFFFFFFFFFFFFFF @ chrome.dll+EC1491E

Exact Browser Use sequence

The transcript and desktop log agree on this sequence:

  1. A Browser call executed qaTab = await browser.tabs.new() while qaTab was not declared.
  2. The right-hand side completed first and created Browser Use tab 2; assignment then failed with qaTab is not defined. This left tab 2 open without a usable JS handle (an orphan).
  3. The retry used var qaTab2 = await browser.tabs.new() and successfully created tab 3. Tool metadata explicitly reported openTabIds:["2","3"].
  4. The subsequent Browser QA calls used only tab 3; orphan tab 2 remained in the same route/session.
  5. At the end, await qaTab2.close() completed successfully. Tool metadata then reported openTabIds:["2"].
  6. No browser.tabs.finalize(...) call was made.
  7. Codex tore down tab 3, activated the orphan tab 2, emitted the same iab rejected tab for route condition with tabRouteKey=null, then logged Failed to upsert Browser Use PiP content.
  8. The desktop log ended and the browser main process crashed within the same ~200 ms window.

This occurrence therefore did not close the last tab. It closed the active Browser Use webview while another orphaned Browser Use webview remained, forcing an active-tab/route switch during teardown. That distinction may explain why simple one-tab tests did not reproduce the crash.

Reproduction coverage

Earlier controlled one-tab close tests were clean (7/7) on an older build. They did not exercise:

  • a failed tabs.new() call that leaves a created tab orphaned,
  • two Browser Use guests in the same route,
  • teardown of the active guest followed by activation of the orphan,
  • the route mismatch + PiP upsert failure transition.

Related report #35210 covers a similar whole-app exit through browser.tabs.finalize(); this occurrence used direct Tab.close(), so both paths may converge on the same Windows IAB guest teardown/switch lifecycle.

Preserved private artifacts

Raw artifacts are intentionally not attached publicly because dumps and complete logs may contain process memory and session data. They are available privately if maintainers request them.

  • Minidump SHA-256: 65CFFEDED75BBCD8F4BE1B7232F9C5D815BE748FF6203FC102F54A0F8B58800D
  • Sentry envelope SHA-256: 0912CABA44AEA44D20E61AD5ACAFC2A4DB8DFA4195BCC4615D942BC5CCA585D7
  • Desktop log SHA-256: CB3C1AE9E356ADA85509FFD17038D29530577F87041D5C46496812CED6810570

The Sentry session marker records status=crashed, errors=1. The event ID above should allow OpenAI to correlate the full native envelope without exposing it in the public issue.

Cataphract450 · 1 month ago

Codex in-app feedback has now also been submitted for this incident.

  • Feedback ID: 019f7da5-cf7d-7522-ac78-56307105ceb6
  • Sentry event ID: 908bf39d18a64ff58ec81dd7363cb7b8
  • App UI reported that diagnostic-data upload was still completing when the ID became available.

These identifiers should allow the private feedback/session diagnostics and the native Sentry crash envelope to be correlated with this public issue.

fe-nix · 25 days ago

Additional reproduction on 26.727.6591.0 (2026-08-03)

This failure reproduced again on a newer Windows desktop build.

Environment

  • Codex package/version: 26.727.6591.0 x64
  • OS: Windows 10 Home x64, build 19045
  • Workload: an active local frontend task using the in-app Browser for mobile E2E verification, plus local Nuxt and mock API Node processes

Sequence

  1. Mobile Browser verification completed successfully.
  2. The Browser viewport was reset and the Browser tabs were finalized at the end of the test.
  3. Codex Desktop then disappeared unexpectedly while the task was still active.
  4. After reopening the app/task, the two local Node test servers were still listening on ports 3001 and 3002 and had to be identified and stopped manually.
  5. The task changes persisted, but the assistant turn was interrupted before final build/cleanup.

This closely matches the Browser WebView teardown/finalize lifecycle reported here and shows that the issue still occurs on 26.727.6591.0. It also confirms that child processes launched for the active task can remain alive after the desktop app terminates.

No raw logs, local paths, thread identifiers, or project contents are included in this public comment.