Repository navigation
[Windows desktop] Closing in-app Browser tab silently terminates Codex during WebView teardown #34239
Description
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
- A Codex task used Browser Use against a local frontend while a Node/Vite test server was running.
- The focused browser verification completed successfully.
- The Browser Use tab was closed.
- Codex logged route rejection during teardown with
tabRouteKey=null. - The renderer disposed and removed the browser sidebar WebView, and the browser registry closed the page.
- The desktop log ended at
2026-07-19T17:35:58.604Zwith no shutdown or error record. - Windows destroyed the Codex Desktop AppX container at approximately
2026-07-20 00:36:00.171 +07:00. - 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.
Activity
github-actions commentedon Jul 19, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Cataphract450 commentedon Jul 29, 2026
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
OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g026.721.41059150.0.7871.128ChatGPT.exeprocess, not renderer or GPU0xC0000005read access violation0xFFFFFFFFFFFFFFFFchrome.dll+0xEC1491E908bf39d18a64ff58ec81dd7363cb7b82026-07-29 10:53:04 MSK/07:53:04ZThe 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:Exact Browser Use sequence
The transcript and desktop log agree on this sequence:
qaTab = await browser.tabs.new()whileqaTabwas not declared.2; assignment then failed withqaTab is not defined. This left tab2open without a usable JS handle (an orphan).var qaTab2 = await browser.tabs.new()and successfully created tab3. Tool metadata explicitly reportedopenTabIds:["2","3"].3; orphan tab2remained in the same route/session.await qaTab2.close()completed successfully. Tool metadata then reportedopenTabIds:["2"].browser.tabs.finalize(...)call was made.3, activated the orphan tab2, emitted the sameiab rejected tab for routecondition withtabRouteKey=null, then loggedFailed to upsert Browser Use PiP content.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:
tabs.new()call that leaves a created tab orphaned,Related report #35210 covers a similar whole-app exit through
browser.tabs.finalize(); this occurrence used directTab.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.
65CFFEDED75BBCD8F4BE1B7232F9C5D815BE748FF6203FC102F54A0F8B58800D0912CABA44AEA44D20E61AD5ACAFC2A4DB8DFA4195BCC4615D942BC5CCA585D7CB3C1AE9E356ADA85509FFD17038D29530577F87041D5C46496812CED6810570The 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 commentedon Jul 29, 2026
Codex in-app feedback has now also been submitted for this incident.
019f7da5-cf7d-7522-ac78-56307105ceb6908bf39d18a64ff58ec81dd7363cb7b8These identifiers should allow the private feedback/session diagnostics and the native Sentry crash envelope to be correlated with this public issue.
fe-nix commentedon Aug 3, 2026
Additional reproduction on 26.727.6591.0 (2026-08-03)
This failure reproduced again on a newer Windows desktop build.
Environment
26.727.6591.0x6419045Sequence
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.
Grokhen commentedon Sep 5, 2026
Two additional crashes on Windows package 26.901.5280.0 — 2026-09-05
The same failure pattern occurred twice during an active local frontend task. Both incidents are supported by the task transcript, desktop lifecycle log, and Crashpad sidecar metadata.
Environment
OpenAI.Codex_26.901.5280.0_x64__2p2nqsd0c76g0ChatGPT.exeObserved sequence and timestamps
All timestamps below are UTC.
await tab.close();invoked at 11:09:14.822reason=target-closeat 11:09:18.167, followed by guest/WebView teardown; log ends at 11:09:18.200await inboxTab.close();invoked at 15:37:08.258reason=target-closeat 15:37:08.275, followed by guest/WebView teardown; log ends at 15:37:08.311Both close calls returned without a tool error. The desktop application nevertheless disappeared and the active work was interrupted.
The two independently created Crashpad sidecar files contain the same metadata:
{"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}The last tab-lifecycle counters were:
action=closed appBrowserTabCount=0 appBrowserUseTabCount=0action=closed appBrowserTabCount=1 appBrowserUseTabCount=0Before incident 2, the log also repeatedly reported
Failed to upsert Browser Use PiP content, and at 15:35:39.181 reportedNo ChatGPT browser route is available for browser session(session identifier omitted).Expected and actual behavior
Closing a temporary verification tab should leave the desktop app and active task running. Instead, the browser process crashed at the teardown boundary, preventing the assistant from completing its turn. Already-written project changes remained on disk.
These are two observed occurrences on one machine, not a controlled minimal reproduction. No symbolized crash dump is available, so the exact faulting module or memory error has not been established. The timing and sidecar metadata strongly implicate the Browser Use teardown path.
Only selected diagnostic facts are included here; personal paths, project source, credentials, full transcripts, and session identifiers are omitted.
jamthy commentedon Sep 5, 2026
Three additional Windows crashes on 26.901.5003.0, including automatic turn-ended IAB teardown (2026-09-05)
The desktop app disappeared repeatedly during local frontend verification. Read-only inspection of desktop logs, the task transcript, and three separate Crashpad sidecars found the same Browser Use WebView teardown boundary.
Environment
10.0.26200, x64.26.901.5003.0.ChatGPT.exe.Correlated occurrences
All dates are 2026-09-05. The final column is the Crashpad sidecar's filesystem modification time, not a symbolized exception timestamp.
Each of the three sidecars contains:
{"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}After the latest occurrence, the desktop process was started again at approximately 23:59:12 UTC+08:00.
Additional trigger detail: automatic cleanup at turn end
For incidents 2 and 3, the desktop log explicitly records
reason=turn-endedwhen unregistering the browser debugger listener, immediately before disposal of the browser sidebar guest. The surrounding task tool calls performed ordinary local page interaction; the inspected 23:00–24:00 transcript contains no agent-issued process-kill, application-close, or shutdown command.This adds an automatic end-of-turn cleanup path to the explicit
tab.close()/reason=target-closeoccurrences already reported here.Latest failure boundary (UTC; identifiers omitted and lines shortened):
Before this occurrence, the log also recorded
No ChatGPT browser route is available for browser sessionat 15:55:41.413Z and repeatedFailed to upsert Browser Use PiP contentwarnings. The browser route was associated with aclient-new-thread:placeholder while Browser Use requests originated from a persisted task ID; actual identifiers are omitted.Expected behavior and evidence limits
Ending a Browser Use turn and cleaning up its temporary WebView should leave the desktop app running. Instead, the app disappeared at the teardown boundary on three occasions, repeatedly interrupting the user's workflow.
No corresponding Codex Windows Application Error/Hang/WER entry was found during the inspected evening, but the Crashpad sidecars explicitly record crashes. Only the sidecars remained in the inspected Crashpad reports directory; no full minidump or symbolized stack was available. The teardown timing is strongly correlated, but neither the exact faulting module nor the ResizeObserver warning is established as the root cause. These are observed occurrences, not a deterministic minimal reproduction.
Please investigate the Windows browser-process lifecycle during automatic
turn-endedcleanup as well as explicit tab closure. Full transcripts, local usernames/paths, project contents, credentials, and account identifiers are not included in this public report.bin131040-a11y commentedon Sep 8, 2026
Reproduction on 26.901.6511: explicit close and automatic task-completion teardown
I reproduced this twice on the current Microsoft Store build. The second occurrence also shows that reaching the last Browser Use tab is not required.
Environment
OpenAI.Codex_26.901.6511.0_x640.153.4152.0.7977.83The package updated from
26.901.5003to26.901.6511on 2026-09-07. Both occurrences below were on26.901.6511.Occurrence A: explicit managed-tab close
Local time: 2026-09-07 21:49:52 (UTC+08:00).
The task executed:
The tool event was persisted as completed. The desktop log immediately recorded:
Crashpad then created a browser-process crash sidecar:
{"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}Occurrence B: automatic cleanup after subagent completion
Local time: 2026-09-08 18:44:29 (UTC+08:00).
There was no explicit
close()ortabs.finalize()call. A subagent used one managed IAB tab, sent its final answer, and reachedtask_complete. About 30 ms later the desktop automatically ended the Browser Use session:Crashpad again recorded the same browser-process classification:
{"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}The affected tab was still owned by a temporary route:
while session activity ended for the assigned real conversation ID. This is consistent with the stale-route/rebinding evidence already discussed in related reports.
Current packaged-code clue
Read-only inspection of the installed
app.asarshows this current main-process helper:The renderer-side
dispose()removes the<webview>and clears its container, which initiates guest teardown before the main process performs the separateisDestroyed()check andclose()call. This is a concrete check-then-act/re-entrant teardown race candidate. I am not claiming the exact native instruction without a retained local minidump.No matching OOM, GPU reset, Defender, Code Integrity, or normal Application Error event was found at either boundary. The first occurrence also had an AppModel Runtime event 217 destroying the Codex AppX container immediately afterward.
These reproductions extend the affected range to
26.901.6511and show that explicit close, last-tab transition, and zero remaining Browser Use tabs are not required. The common invariant is managed IAB guest-WebContents teardown.DiNaSoR commentedon Sep 12, 2026
Still occurring on Windows 26.908.4834.0 — three additional exits on 2026-09-12
Three unexpected whole-app exits were observed on one machine, each immediately after the agent explicitly closed an in-app Browser Use tab. The task transcripts, desktop logs, and Windows AppModel-Runtime events agree on the timing.
Environment
Correlated occurrences
All timestamps below are UTC on 2026-09-12. Windows event times are shown to whole-second precision.
await bankTab.close();at 16:13:04.402await civilTab.close();at 16:46:52.525await adminFixTab.close();at 20:23:20.501The calls were issued through
mcp__cua_repl/jsto close temporary verification tabs. The first two calls were recorded as successfully completed. The user did not intentionally quit Codex. After occurrence 3, no Codex desktop ChatGPT.exe processes remained; an unrelated IDE Codex process was still running.Latest failure boundary
Selected desktop lines are shortened and identifiers omitted:
The affected browser route used a
client-new-thread:<redacted>owner while Browser Use actions originated from a persisted conversation ID. This is additional context, not proof of the underlying fault.Diagnostics and limits
Expected: closing a temporary browser tab leaves the Codex app and active task running.
Actual: the desktop app disappears immediately after browser-tab cleanup, interrupting work.
Avoiding explicit
.close()and reusing tabs has been suggested as a temporary workaround but has not yet been verified on this machine.