›_ Codex Issues
Codex Issues / #36645

[Windows] Codex App exits after task completion when Browser Use session tears down

Open 💬 10 comments Opened Aug 3, 2026 by brokenbread42205
💡 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.727.6591.0

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

After the task-complete notification appears, the entire Codex desktop app closes.

This occurred twice while Browser Use had been used for local web-app QA. On the second occurrence, no explicit browser.tabs.finalize() call was made.

Local Codex logs from approximately 8:15:35–8:15:41 PM America/Chicago show repeated renderer errors:

[desktop-notifications][global-error] ResizeObserver loop completed with undelivered notifications.

The log then records the Browser Use session activity ending, debugger listeners being unregistered, both browser sidebar webviews being disposed, and the app browser-tab count reaching zero. The process log stops immediately afterward. A new Codex process began about seven seconds later.

Windows Event Viewer contained no corresponding Application Error or Windows Error Reporting event, and the Codex log contained no explicit fatal/shutdown line.

What steps can reproduce the bug?

  1. Open Codex App on Windows and work in a normal coding task.
  2. Use the Codex in-app Browser/Browser Use during the task for local UI verification.
  3. Complete the task and allow Codex to return its final response.
  4. Observe the task-complete popup.
  5. Within seconds, the entire Codex desktop application closes.

Reproduced twice in the same task sequence:

  • First occurrence followed explicit browser-tab cleanup.
  • Second occurrence happened without calling browser.tabs.finalize(); the logs show automatic Browser Use teardown as the session activity ended.

Thread/session ID: 019f96ca-a681-7751-809b-2f1f7c16fc9f
Affected turn ID: 019fc50f-0b83-73f0-9915-70c156e567ec

What is the expected behavior?

Completing a task and releasing Browser Use resources should leave the Codex desktop application running. Only the Browser Use session or its tabs should be released.

Additional information

The coding task completed successfully before the shutdown, and repository changes remained intact after restarting Codex.

The final logged sequence strongly correlates the exit with Browser Use/webview teardown and a burst of ResizeObserver notification errors, but there is no explicit fatal exception, so the exact root cause is not proven.

No raw logs are attached because they may contain sensitive data. Sanitized excerpts can be supplied if requested.

Related issue #35425 covers a similar shutdown after an explicit browser.tabs.finalize({ keep: [] }) call. This report remains distinct because the second reproduction occurred without an explicit finalize call; automatic end-of-task session teardown produced the same whole-app exit.

View original on GitHub ↗

10 Comments

github-actions[bot] contributor · 25 days ago

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

  • #35425

Powered by Codex Action

gimkim · 21 days ago

Reproduced twice on a newer Windows desktop build, Codex 26.803.5235.0, after Microsoft Store updated the app from 26.730.8199.0 on 2026-08-07.

Both occurrences were in the same long-running coding task after using the in-app Browser:

  • Occurrence 1: final controlled Browser tab was closed/finalized at 11:28:47 local time; Windows AppModel-Runtime event 217 destroyed the Codex Desktop AppX container at 11:28:48; the app relaunched at 11:28:51.
  • Occurrence 2: logs showed repeated Node with given id does not belong to the document and ResizeObserver loop completed with undelivered notifications; final Browser tab teardown occurred at 11:35:04; AppX container was destroyed at 11:35:05; the app relaunched at 11:35:07.

No matching Windows Application Error, WER crash report, local crash dump, OOM evidence, or explicit fatal/shutdown marker was found. The strongest correlation is still teardown of the last Browser Use / in-app Browser tab. Source edits remained intact, but the active task was interrupted.

Expected: releasing the final Browser Use tab should leave Codex Desktop running.
Actual: the entire desktop app silently exits and restarts.

Sanitized log excerpts can be supplied if maintainers need them; raw logs are not attached because they contain local paths and task metadata.

psbase · 19 days ago

Correction:

### What subscription do you have?

ChatGPT Pro 20x

### What platform is your computer?

Windows 11 Pro 25H2, OS Build 26200.8875

arellen912007 · 19 days ago

Additional confirmed reproduction on 2026-08-09 (Asia/Shanghai) with the current Windows build:

  • App release: codex@26.803.41515
  • Microsoft Store package: OpenAI.Codex_26.803.5235.0_x64__2p2nqsd0c76g0
  • Electron/Chromium: 151.0.7922.76
  • OS: Windows 11 x64, build 26200

Two independent exits showed the same timing:

  1. Final Browser Use teardown log: 11:33:35.698; Crashpad sidecar: 11:33:36.099 (+402 ms).
  2. Final Browser Use teardown log: 13:07:32.541; Crashpad sidecar: 13:07:32.974 (+433 ms).

Both Crashpad sidecars contain:

{"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}

The common final desktop-log sequence was:

IAB_LIFECYCLE unregistered debugger listener ... reason=manual ... webContentsDestroyed=false
IAB_LIFECYCLE renderer disposed browser sidebar webview ...
IAB_LIFECYCLE browser sidebar guest torn down ...
IAB_LIFECYCLE renderer removed browser sidebar webview ... tabType=closed
IAB_LIFECYCLE closed browser sidebar page ...

The entire app then exited, and Microsoft-Windows-AppModel-Runtime Event 217 destroyed the AppX container immediately afterward. There were no corresponding Windows Application Error, Application Hang, WER, Kernel-Power 41, WHEA, Display/TDR, or resource-exhaustion events.

Crashpad report UUIDs:

  • 7adf32a0-a28e-4aee-b453-1d9d7fa9b462
  • 2c9400d7-cdff-4bc3-b6e8-2270bf9fe890

The second occurrence had several ResizeObserver warnings before teardown, but the first did not. The first had a temporary pubsub disconnect that recovered, while the second did not. Neither is therefore a common prerequisite. The strongest shared trigger remains teardown of the last Browser Use guest WebContents.

Only sanitized sidecar metadata remains locally; the minidumps were already removed/uploaded by Crashpad. Full logs are not attached because they contain conversation IDs, local paths, and task content. Targeted sanitized excerpts can be provided if needed.

iharc-jordan · 17 days ago

Additional reproduction from Windows (America/Toronto, 2026-08-09/10):

  • Microsoft Store package: OpenAI.Codex_26.803.5235.0_x64__2p2nqsd0c76g0
  • App/Browser release: 26.803.41515
  • Electron/Chromium: 151.0.7922.76
  • Windows 11 x64, build 26200.8875

Three separate whole-app crashes occurred:

  • 2026-08-09 22:25:41 EDT
  • 2026-08-09 23:22:35 EDT
  • 2026-08-10 08:18:24 EDT

Each desktop log ended immediately after the same IAB teardown boundary:

unregistered debugger listener (reason=manual, webContentsDestroyed=false)
renderer disposed browser sidebar webview
browser sidebar guest torn down
renderer removed browser sidebar webview
closed browser sidebar page
browser tab lifecycle action=closed (appBrowserTabCount=0)

A Crashpad sidecar appeared within the next second every time:

{"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}

Two occurrences also logged Cannot find context with specified id and Failed to upsert Browser Use PiP content before teardown.

There was no matching Windows Application Error/WER, display/TDR, WHEA, resource-exhaustion, or package-registration failure. Package status was healthy. A fourth matching crash occurred Aug 7 on the prior 26.730.8199.0 package; multiple full Windows restarts occurred before these three later reproductions, so rebooting did not prevent it.

This supports the existing finding that the current main/browser process crashes during final IAB guest/WebView teardown. Automatic teardown is unsafe as well as explicit finalization; the reliable workaround here is avoiding Codex IAB/Browser Use entirely and using external Chrome or CLI browser verification.

iharc-jordan · 17 days ago

Follow-up after comparing successful and failed in-app Browser runs in retained Windows logs from July 27 through August 10:

  • 142 Browser guest teardown events were recorded.
  • After 135, the same Codex desktop process continued logging for at least another 30 seconds.
  • Four teardowns have matching Crashpad browser-process crashes. Three additional short process endings were too close to ordinary shutdown/restart boundaries to classify.
  • 16 teardowns involved tabs whose conversationId was a real Codex task/session ID; none crashed.
  • 126 involved a provisional client-new-thread:* route; four crashed and 122 completed cleanly. This is therefore a correlation and likely race condition, not a deterministic trigger.
  • One delegated/internal route on package 26.730.8199.0 used a task-bound IAB tab extensively for navigation and screenshots, finalized its last tab with keep:[], and then auto-disposed its route cleanly. The first crash occurred on that same package the following day, so delegation and app version alone are not sufficient triggers.
  • In two crashes on 26.803.5235.0, an IAB request under the actual task ID first failed with Cannot find context with specified id; teardown then closed a different tab owned by a client-new-thread:* route.

Working hypothesis: stale/provisional route ownership, or a failure to promote/rebind that route to the active Codex task, increases the likelihood of the final guest WebContents teardown race.

Potential investigation point: route promotion/rebinding and teardown when the active Codex session ID differs from the Browser page routeKey/conversationId.

Narrower workaround observed from successful runs:

  • use a separate user-visible Codex task as the Browser owner;
  • acquire and reuse only a task-local Browser binding and task-created tab;
  • never share tabs or bindings across tasks;
  • on missing-context errors, discard the stale tab handle without closing/finalizing that route;
  • preserve the final tab for handoff instead of closing it.

This supersedes my earlier statement that avoiding IAB entirely was the only reliable workaround.

iharc-jordan · 17 days ago

Follow-up: the narrower workaround in my previous comment is not reliable.

A new whole-app crash occurred on 2026-08-10 at 15:35:04 EDT while using a separate user-visible delegated Codex task as the Browser owner. The task followed the proposed precautions:

  • acquired its own task-local in-app Browser binding;
  • created and reused one fresh task-local tab;
  • did not use an internal subagent for Browser work;
  • did not call tabs.finalize({keep:[]}), close the tab, or otherwise request Browser teardown;
  • explicitly preserved the tab when handing off its final result.

The active Codex task/conversation ID was 019fed22-456a-7760-a028-f98fa5377d73. Immediately after its final response, the desktop app logged automatic session cleanup for that ID:

unregistered debugger listener ... pageKey=1:client-new-thread:39871b62-... reason=session-activity-ended ... webContentsId=38
ended browser use session activity conversationId=019fed22-456a-7760-a028-f98fa5377d73 disposeAfterSessionActivity=false
renderer disposed browser sidebar webview
browser sidebar guest torn down
closed browser sidebar page

The Crashpad sidecar followed approximately 0.6 seconds later and again reported:

{"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}

At teardown, analytics still reported appBrowserTabCount=3 and appBrowserUseTabCount=2. Therefore, teardown of the globally final Browser tab is not a necessary condition.

This reproduction strengthens the route-ownership hypothesis: the session cleanup was associated with the real task ID, but the Browser page was still registered under a provisional client-new-thread:* route. It also demonstrates that creating a separate user-visible task and preserving its final tab does not ensure that the Browser route is promoted/rebound correctly, nor does it prevent automatic teardown at task completion.

Revised workaround status: I no longer consider delegated user-visible tasks with task-local IAB tabs safe. Until route promotion and session-end teardown are fixed, avoiding the in-app Browser remains the only workaround supported by these reproductions.

iharc-jordan · 17 days ago

Additional conclusive repro from August 10, 2026 at 3:35:04 PM EDT.

Triggering delegated task:

  • Title: Audit STEVI as family F2
  • Task ID: 019fed22-456a-7760-a028-f98fa5377d73
  • Parent: Plan kiosk home hub audit

Observed sequence:

  1. The separate user-visible delegated task completed.
  2. Codex automatically ended that task's Browser session.
  3. Teardown targeted a tab registered under a provisional client-new-thread:* route instead of the task's real ID.
  4. The Browser process crashed approximately 0.6 seconds later.

The task followed the previously proposed isolation workaround:

  • one task-local in-app Browser binding and one task-created tab;
  • no Browser delegation to internal subagents;
  • no shared/inherited tab or binding;
  • no manual tab close;
  • no tabs.finalize({keep:[]}) or generic cleanup;
  • the tab was explicitly preserved for handoff.

Three other Browser tabs remained at the time, so this is not limited to closing the final tab.

This indicates that separate user-visible delegated tasks are not a reliable workaround. The failure appears to be automatic session-end teardown acting on an incorrectly bound provisional task route. No files or settings were changed while establishing this incident sequence.

amarmehdaouiocb · 17 days ago

Confirmed on a newer Windows build. The same Browser Use teardown crash still occurs on the current Microsoft Store package available on this machine.

Environment

  • Microsoft Store package: OpenAI.Codex_26.803.10989.0_x64__2p2nqsd0c76g0
  • Browser release reported by desktop logs: 26.803.81509
  • Electron/Chromium file version: 151.0.7922.76
  • Windows x64 build: 26200.8875
  • Local timezone: Europe/Paris (UTC+2)

Timeline (2026-08-11)

  • 12:47:28: Browser Use opened an in-app browser page.
  • 12:48:00: the page reached dom-ready.
  • 12:48:04.178: IAB_LIFECYCLE unregistered debugger listener ... reason=manual ... webContentsDestroyed=false
  • The app then logged the usual teardown sequence: renderer disposed the browser sidebar webview, guest WebContents torn down, tab removed, page closed, and browser tab count reached zero.
  • 12:48:04.201: final desktop log entry.
  • 12:48:04.630: Crashpad sidecar created (+429 ms), containing:
{"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}
  • Windows AppModel-Runtime event 217 then recorded destruction of the AppX container.
  • 12:51:34: the user manually relaunched Codex.

Crashpad report UUID: 0262920b-8002-4408-834e-0a82f5812bf8

The Browser page was still registered under a provisional client-new-thread:* route while the active task had a real session ID, which is consistent with the route ownership/rebinding hypothesis discussed above. A Failed to upsert Browser Use PiP content warning also appeared immediately before teardown.

There was no matching Windows Application Error, Application Hang, WER report, resource-exhaustion event, display/TDR event, or app update/deployment event at the crash time. Full logs are not attached because they contain local paths, task metadata, and a private web-app URL; sanitized excerpts can be provided if needed.

Expected: tearing down the Browser Use WebContents should leave Codex Desktop running.
Actual: the main/browser process crashes and the whole desktop app exits.

Phili110 · 13 days ago

Additional confirmation on a newer Windows build (2026-08-14, Europe/Berlin).

Environment

  • Microsoft Store package: OpenAI.Codex_26.810.4967.0_x64__2p2nqsd0c76g0
  • Bundled Browser client release: 26.803.41515
  • Platform: Windows x64

Reproduction

The whole-app exit occurred repeatedly after a task using the in-app Browser completed. For the latest occurrence:

  • no explicit browser.tabs.finalize() call was made;
  • no manual tab-close action was requested;
  • automatic session cleanup began at task completion;
  • the desktop process disappeared and Codex relaunched roughly 14 seconds later.

The sanitized final sequence in the old desktop log was:

unregistered debugger listener ... reason=session-activity-ended
syncing browser use active state ... isActive=false
renderer disposed browser sidebar webview
browser sidebar guest torn down
renderer removed browser sidebar webview ... tabType=closed
closed browser sidebar page
<desktop process log ends approximately 100 ms later>

There was no matching Windows Application Error, Windows Error Reporting, or .NET Runtime event.

Additional implementation clue

The IAB backend advertised both Tab.markDeliverable and Tab.markHandoff as supported, but the bundled Browser client wrapper exposed both methods as undefined. Read-only inspection showed that its global disabled-member filter suppressed these two methods before per-browser capability overrides were applied. Consequently, an agent-created IAB tab could reach automatic turn-end teardown without the client providing the advertised retention methods.

As a local diagnostic workaround, enabling the two mark methods, keeping Tabs.finalize unavailable, and marking the agent-created tab as deliverable allowed a controlled in-app Browser turn to complete without the immediately observed teardown crash. This is limited local evidence, not a confirmed upstream fix.

No raw logs, local paths, task IDs, or private page data are included here.