Skip to content

[Windows] Finalizing the last in-app Browser Use tab closes/restarts Codex Desktop #36674

Open
Open
[Windows] Finalizing the last in-app Browser Use tab closes/restarts Codex Desktop#36674
Labels
appIssues related to the Codex desktop appbrowserbugSomething isn't workingwindows-osIssues related to Codex on Windows systems

Description

@talha-khan
talha-khan
opened on Aug 3, 2026

What version of the Codex App are you using?

  • Microsoft Store package: OpenAI.Codex_26.727.6591.0_x64__2p2nqsd0c76g0
  • In-app Browser runtime release from logs: 26.727.51351

What platform is your computer?

Microsoft Windows NT 10.0.26200.0, x64.

What issue are you seeing?

Finishing a QA run by finalizing the last managed in-app Browser Use tab causes the entire Codex Desktop app to close and restart.

This is not a normal task completion. The QA turn remains interrupted, the desktop log stops without a normal shutdown sequence, and a new Codex process starts roughly five seconds later.

Steps to reproduce

  1. Open Codex Desktop on Windows.
  2. Start a task that uses the in-app Browser.
  3. Open and use one managed Browser Use tab.
  4. At the end of the task, run: 
    await browser.tabs.finalize({ keep: [] });
  5. Observe that the last Browser Use tab closes.
  6. Codex Desktop then closes/restarts and the active QA turn is left interrupted.

Expected behavior

The managed browser tabs should close while Codex Desktop remains open. The task should be able to send its final answer and reach a completed state.

An empty managed-tab list is documented as valid browser cleanup state and should not invalidate the browser binding or terminate the desktop host.

Actual behavior

The finalization call returns successfully, but closing the final Browser Use tab is immediately followed by silent desktop-process termination.

Sanitized timeline from the latest reproduction:

02:27:38.220Z unregistered debugger listener reason=manual
02:27:38.222Z renderer disposed browser sidebar webview
02:27:38.228Z browser sidebar guest torn down
02:27:38.232Z renderer removed browser sidebar webview tabType=closed
02:27:38.232Z closed browser sidebar page
02:27:38.232Z browser tab lifecycle action=closed appBrowserTabCount=0 appBrowserUseTabCount=0
02:27:38.237Z final records in the old desktop log
02:27:43.290Z new desktop process: "Launching app"

The associated QA thread was persisted with status interrupted, despite the browser.tabs.finalize({ keep: [] }) tool call completing successfully.

Additional diagnostics

  • Windows Event Viewer contains no matching Application Error, Windows Error Reporting, or .NET Runtime crash event.
  • The same browser-sidebar teardown-at-end-of-log pattern appears in several earlier Codex Desktop sessions.
  • Before teardown, the log repeatedly reports: 
    IAB_LIFECYCLE iab backend request failed: Cannot find context with specified id
Failed to upsert Browser Use PiP content
  • The QA session ID for the latest reproduction is 019fc56c-743d-7560-90e6-3e491f30782d.
  • Full desktop logs are not attached publicly because they may contain local paths and session metadata; targeted excerpts can be provided privately.

Workaround

Do not finalize the final in-app Browser tab. Leaving one managed tab open, or using an external Chrome browser for QA, avoids this cleanup trigger.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    browser
    on Aug 3, 2026

  2. github-actions commented on Aug 3, 2026

    @github-actions
    github-actionsbot
    on Aug 3, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. carlosesquivelroisenvit commented on Aug 21, 2026

    @carlosesquivelroisenvit
    carlosesquivelroisenvit
    on Aug 21, 2026

    I can confirm the same failure on two newer Codex Desktop builds.

    • At least 10 abnormal app exits during the past week.
    • Four surviving Crashpad sidecars explicitly classify the failures as Electron browser-process crashes.
    • Three crashes occurred on 26.814.5517.0; the latest occurred on 26.818.3698.0, so the update did not resolve it.
    • The latest two crashes share the same final sequence: failed PiP updates and stale CDP contexts, reason=target-close, browser guest teardown, route rejection with tabRouteKey=null, Browser Use tab count reaching zero, immediate browser-host recreation, undefined PiP tab metadata, then a Crashpad browser-process crash within about one second.
    • codex doctor passed the relevant checks, and Windows System, Defender, Code Integrity, AppLocker, and Resource Exhaustion logs contained no matching event.
    • The sandbox ACL state was valid after the latest crash, so that was not the trigger.

    I have attached a privacy-reviewed evidence bundle containing the full report, two targeted log excerpts, four 60-byte Crashpad sidecars, and SHA-256 checksums. It excludes full logs, transcripts, prompts, responses, credentials, configuration, and browser-profile data.

    codex-desktop-crash-20260821.zip

  4. Lukansyberia commented on Aug 23, 2026

    @Lukansyberia
    Lukansyberia
    on Aug 23, 2026

    I can confirm this is still reproducible on a newer Windows build, and I was able to narrow the lifecycle condition with a controlled A/B test.

    Environment

    • Microsoft Store package: OpenAI.Codex_26.818.5229.0_x64__2p2nqsd0c76g0
    • Electron/Chromium executable version: 151.0.7922.170
    • Windows x64
    • Built-in managed Browser Use / IAB backend

    Reproduction: last managed Browser Use tab

    A realistic localhost Browser Use workflow completed successfully:

    • login/authentication;
    • multiple GET/POST interactions;
    • several pages/navigations;
    • DOM/state observations;
    • no download;
    • no print.

    Immediately before closing the only managed Browser Use tab, an external marker was persisted:

    22:37:50.833 REALISTIC_NO_DOWNLOAD_WORKFLOW_CONFIRMED
22:37:51.814 BEFORE_TAB_CLOSE

    There was no AFTER_TAB_CLOSE.

    Desktop lifecycle logging then showed:

    IAB_LIFECYCLE unregistered debugger listener ... reason=target-close
IAB_LIFECYCLE syncing browser use active state ... isActive=false
IAB_LIFECYCLE iab rejected tab for route ... tabRouteKey=null
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
IAB_TAB_ANALYTICS browser tab lifecycle action=closed
    appBrowserTabCount=1
    appBrowserUseTabCount=0

    A normal/non-Browser-Use app-browser tab was still present (appBrowserTabCount=1), so merely keeping an ordinary sidebar browser tab alive did not prevent the crash.

    Approximately one second later the Codex AppX container was destroyed.

    Crash evidence

    This reproduction preserved a Crashpad minidump rather than only the usual 60-byte sidecar.

    Crashpad sidecar:

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

    Minidump:

    thread:       CrBrowserMain
exception:    0xC0000005 ACCESS_VIOLATION
operation:    READ
module:       chrome.dll
version:      151.0.7922.170
RAX:          0xEFEFEFEFEFEFEFEF

    The faulting instruction dereferenced the poisoned-looking RAX value. This is consistent with a dangling/use-after-free style native teardown failure.

    Windows did not create a corresponding Application Error / WER crash record, but AppModel-Runtime recorded destruction of the OpenAI.Codex desktop AppX container immediately afterward.

    Important control: 2 -> 1 managed tabs

    I then ran a separate control designed specifically to distinguish:

    • closing an arbitrary stateful managed Browser Use tab; from
    • closing the last managed Browser Use tab.

    Sequence:

    1. Create managed TAB_A.
    2. Run the complete realistic localhost workflow in TAB_A.
    3. Create a second managed TAB_B sentinel on about:blank.
    4. Confirm managed Browser Use count = 2.
    5. Close TAB_A by its exact ID while TAB_B remains.
    6. Confirm managed Browser Use count = 1.
    7. Keep TAB_B open.
    8. Stop all Browser Use calls.
    9. Wait 30 seconds and complete the task normally.

    Result:

    2 managed Browser Use tabs
-> close stateful TAB_A
-> 1 managed Browser Use tab remains
-> PASS

    Relevant persistent markers:

    PRE_CLOSE_TWO_MANAGED_TABS_CONFIRMED
BEFORE_CLOSE_TAB_A
AFTER_CLOSE_TAB_A
MANAGED_COUNT_2_TO_1_CONFIRMED
SENTINEL_TAB_B_SURVIVED
BROWSER_TOOL_USE_FINISHED
POST_BROWSER_WAIT_END
BEFORE_FINAL_REPLY

    The desktop lifecycle log also recorded the close with:

    appBrowserUseTabCount=2
...
reason=target-close tabId=1
...
action=closed appBrowserUseTabCount=1

    PiP metadata subsequently referenced the surviving managed tab (tabID=2).

    The app remained healthy and the task reached its normal final response.

    Current conclusion

    The strongest supported boundary is therefore:

    managed Browser Use count 1 -> 0 : CRASH
managed Browser Use count 2 -> 1 : PASS

    This also shows that:

    • downloads are not required to reproduce the crash;
    • closing a realistic/stateful managed tab is not by itself sufficient;
    • an ordinary non-Browser-Use sidebar tab is not an adequate survivor;
    • preserving at least one managed Browser Use tab avoids the reproduced failure.

    Current workaround on this build is to never finalize/close the final managed Browser Use tab.

    If cleanup is needed, individual managed tabs can be closed while at least one other managed Browser Use tab is intentionally left alive.

  5. witalker commented on Aug 23, 2026

    @witalker
    witalker
    on Aug 23, 2026 – with ChatGPT Codex Connector

    I can corroborate this on the same current Windows build, with a variant that does not require an explicit tabs.finalize({ keep: [] }) call.

    Environment

    • Microsoft Store package: OpenAI.Codex_26.818.5229.0_x64__2p2nqsd0c76g0
    • Desktop/browser runtime release in logs: 26.818.41509
    • Windows x64
    • Built-in managed Browser Use / IAB backend
    • Microsoft Store reports no newer package available

    Three browser-process crashes

    Three separate failures occurred within one night:

    2026-08-23 22:29:56.474 +08:00  fcb8bb14-02a2-478d-95b5-1784de46f0e5
2026-08-24 00:23:14.359 +08:00  d4fc5eb7-4bd1-4a2f-8146-a7ffba80b79b
2026-08-24 07:27:24.870 +08:00  2839c966-c787-4abc-8a6b-87a9c1523350

    All three retained sidecars are identical:

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

    Windows AppModel-Runtime event 217 destroyed the OpenAI.Codex AppX container immediately after each crash. There was no matching Application Error/WER event.

    New reproduction boundary: automatic cleanup at a long-running goal transition

    In all three cases, a long-running goal turn completed and Codex automatically started the next goal turn. The app automatically ended the managed Browser Use session at that boundary; the user did not manually close/finalize the tab.

    Sanitized timeline from the third reproduction:

    07:27:24.087 AgentMessage completed
07:27:24.139 task_complete
07:27:24.143 IAB ended Browser Use session activity
07:27:24.174 task_started (automatic long-running goal continuation)
07:27:24.219 renderer disposed Browser sidebar webview
07:27:24.224 Browser sidebar guest torn down
07:27:24.230 Browser Use tab closed
             appBrowserTabCount=3
             appBrowserUseTabCount=0
07:27:24.870 Crashpad browser-process crash

    The two earlier crashes show the same ordering, with the Crashpad sidecar created about 0.5–1.7 seconds after the final managed Browser Use tab teardown.

    The lifecycle records also show a persisted task id for ended browser use session activity, while the page/route key is under a client-new-thread:<redacted> draft route.

    This extends the reproduction beyond a manual finalization call:

    long-running goal task_complete
+ automatic next task_started
+ automatic managed Browser Use count 1 -> 0
= browser-process crash

    Ordinary app-browser tabs do not protect against it; the third crash still had appBrowserTabCount=3 when managed Browser Use reached zero.

    Impact on other active tasks

    Because the Electron browser/main process exits, unrelated active local tasks are interrupted too. In one affected long-running task:

    • the raw rollout remained on disk (50.36 MB / 10,154 events);
    • it had 13 compaction records;
    • three active turns interrupted by these crashes had no task_complete;
    • after restart, a new goal turn was started from compacted goal context;
    • the app thread API exposed only the original in-progress turn (63 items), while the raw rollout contained 25 user and 213 assistant messages.

    So the failure can cause both lost in-flight context and incomplete UI/thread rehydration even when the raw JSONL survives. This appears adjacent to #25779, but in this case the deterministic initiating event is the final managed IAB teardown.

    Ruled out / workaround

    • No Windows reboot at the crash times.
    • Store update checks returned hasUpdate=false / NoUpdates.
    • No resource-exhaustion event.
    • One crash occurred during Modern Standby, but two occurred while awake, so standby is not the common cause.

    Current reliable workaround is to disable/avoid the bundled in-app Browser plugin and use external Chrome or shell/Playwright-based validation. Preserving a managed IAB sentinel tab should also avoid the 1 -> 0 transition, consistent with the controlled A/B result already reported above.

    Full logs and transcripts are not attached because they contain local project paths and task metadata; targeted sanitized excerpts can be provided if maintainers request them.

  6. Yuzr1 commented on Aug 28, 2026

    @Yuzr1
    Yuzr1
    on Aug 28, 2026 – with ChatGPT Codex Connector

    I can confirm this still reproduces on a substantially newer Windows desktop build.

    Environment

    • Codex Desktop package: OpenAI.Codex_26.825.3734.0_x64
    • Windows: Microsoft Windows NT 10.0.26200.0, x64
    • Time zone: UTC+08:00

    Reproductions on 2026-08-28

    The app produced browser-process Crashpad reports at:

    • 10:42:30 local time
    • 11:14:36 local time
    • 12:00:36 local time

    All three Crashpad sidecars contain:

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

    In each occurrence, the desktop log ends at the in-app Browser Use teardown boundary. The common sanitized sequence is:

    IAB_LIFECYCLE unregistered debugger listener ... reason=target-close
IAB_LIFECYCLE syncing browser use active state ... isActive=false
IAB_LIFECYCLE renderer synced browser use webview state ... isBrowserUseActive=false
IAB_LIFECYCLE iab rejected tab for route ... tabRouteKey=null
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
IAB_TAB_ANALYTICS browser tab lifecycle action=closed

    For the 12:00 occurrence, the final lifecycle record was written at 12:00:35.900; Crashpad recorded the ptype=browser crash at 12:00:36.

    The log also reports Cannot find context with specified id and repeated Failed to upsert Browser Use PiP content messages during Browser Use before teardown. I found no OOM or GPU-process failure at these three boundaries.

    Older-version evidence

    On 2026-08-25, package 26.818.5229.0 also produced repeated codex.exe crashes. Windows Event Viewer recorded exception 0xc0000409 at the same fault offset across several events, and Windows generated multiple crash dumps. This older evidence is not enough to prove the exact same native fault, but it shows that repeated desktop crashes persisted across the update to 26.825.3734.0.

    I am not attaching raw logs or dumps publicly because they contain local paths, browsing history, project URLs, and session metadata. Sanitized excerpts or specific artifacts can be provided if maintainers request them.

    The practical workaround remains avoiding finalization/closure of the last in-app Browser Use tab and using external Chrome for browser QA.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbrowserbugSomething isn't workingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions