Skip to content

Codex Desktop Windows: browser route can disappear mid-workflow and cannot be recovered #43673

Open
Open
Codex Desktop Windows: browser route can disappear mid-workflow and cannot be recovered#43673
Labels
appIssues related to the Codex desktop appbrowserbugSomething isn't workingwindows-osIssues related to Codex on Windows systems

Description

@torudesu113-maker
torudesu113-maker
opened on Sep 8, 2026

Summary

Codex Desktop on Windows lost browser-control routes during a live workflow. The agent could initially operate an in-app browser, prepare a Zazzle product listing, and reach the final publication form, but browser control then became unrecoverable.

This prevented completion of a time-sensitive external workflow and led to repeated attempts that risked creating extra browser-use tabs.

Expected behavior

  • An existing in-app browser tab should remain controllable across turns in the same task.
  • If a route is lost, the agent should be able to create or reconnect to one in-app browser tab and continue.
  • Choosing Chrome as an alternate browser should produce a usable, URL-verifiable browser session.

Actual behavior

  • In-app browser calls such as state retrieval, browser selection, and tab creation timed out.
  • Desktop logs recorded: No ChatGPT browser route is available for browser session ….
  • A delayed hidden browser-use tab could be created under a temporary conversation route, but the active task could not reconnect to it.
  • Retrying could create additional hidden browser-use tabs without restoring control.
  • Chrome fallback also timed out, and the Windows computer-use fallback was stopped because it could not determine the current Chrome URL with enough confidence.

Reproduction outline

  1. Open an authenticated website in Codex Desktop's in-app browser.
  2. Work through a multi-step form until the final publish/submission step.
  3. On a later turn, retrieve browser state or reconnect to the same tab.
  4. Observe the missing browser route, timeout, and inability to recover a single controllable tab.

Impact

The agent reached the final publication form but could not submit or even continue interacting. The user had to be asked to take over despite explicitly requesting end-to-end browser automation.

Environment

  • Codex Desktop for Windows
  • 2026-09-08 JST
  • In-app browser and Chrome fallback both affected

Privacy

This report intentionally omits account details, personal data, local paths, and full logs.

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 Sep 8, 2026

  2. github-actions commented on Sep 8, 2026

    @github-actions
    github-actionsBot
    on Sep 8, 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. staminaoo commented on Sep 9, 2026

    @staminaoo
    staminaoo
    on Sep 9, 2026 – with ChatGPT Codex Connector

    Windows 26.903.61454: browser inventory failure and missing task route

    Additional observation from 2026-09-09 on Windows 11 x64 (build 10.0.26200), desktop MSIX 26.903.8094.0, internal app/browser bundle 26.903.61454.

    An ordinary local task intended to browse public articles became unable to obtain browser state. The task spanned a desktop-app update/restart; this is context, not an established cause.

    Observed sequence

    1. Earlier browser inventories returned Edge and later Chrome.
    2. One earlier extension-browser tab creation timed out, but a later inventory showed the tab had actually been created. A timeout therefore did not reliably mean that the action had no effect.
    3. Later cua.getState() calls repeatedly returned: 
      {
  "browsers": [],
  "errors": ["Browsers: Error: nodeRepl.fetch request failed"]
}
    4. Resetting the provided JavaScript control session and requesting a fresh inventory did not restore access.
    5. Showing the current task and requesting a blank browser panel produced navigated: true / queued UI results, but subsequent browser discovery still failed. Those UI acknowledgments did not establish that a usable browser route existed.

    Matching diagnostic-period log evidence

    The desktop application logged this message for the affected task:

    IAB_LIFECYCLE iab backend info request failed
No ChatGPT browser route is available for browser session <redacted>

    Read-only inspection of the corresponding installed application code found this error in ensureBrowserUseSessionRoute when session-route initialization/lookup does not succeed.

    The absent-route log and the nodeRepl.fetch error were both observed. Their exact causal relationship, and why the route was missing, have not been established. This is not a report of a reproduced app crash or the same subagent-specific lifecycle trigger as other reports.

    Separately, native Windows Chrome inspection also hit the URL-confidence stop; its reproduction and current-artifact findings are recorded in this comment on #25271. A working extension installation does not establish that either control path is healthy.

    Request

    Please provide an actionable diagnostic that distinguishes transport failure from a missing task route, and a supported way to recreate/rebind the route after interruption or restart. Recovery should report actual readiness and avoid creating duplicate tabs when a prior creation timed out.

    No private page content, account identifiers, task IDs, local paths, credentials, or raw logs are attached.

  4. nanyoudegege commented on Sep 11, 2026

    @nanyoudegege
    nanyoudegege
    on Sep 11, 2026

    Independent Windows reproduction on 2026-09-11

    This remains reproducible on a newer build than the original report.

    Environment

    • Windows 11 Pro x64, build 26200
    • Codex Desktop package: 26.903.9818.0
    • Bundled Browser / unified-computer-use release: 26.903.71938
    • Edge ChatGPT extension: 1.26.901.11451

    Observed behavior

    • After fully exiting and restarting Codex Desktop, cua.getState() consistently waits about 21 seconds and returns Browsers: Error: nodeRepl.fetch request failed.
    • Resetting the CUA JavaScript kernel does not recover discovery.
    • A direct cua.createBrowserTab("iab", "about:blank", {visible:false}) call succeeds in under one second, but a subsequent global cua.getState() still fails after about 21 seconds.
    • A direct Edge backend creation attempt fails after the same interval.
    • Desktop lifecycle logs show the IAB backend reaching browser_use_iab_backend_startup_ready; an initial getInfo can complete, followed immediately by repeated getInfo failures for the same active task with No ChatGPT browser route is available for browser session ....

    This narrows the failure to browser inventory/session-route lifecycle or response propagation rather than complete inability to create an IAB WebView.

    Recent-change correlation

    Browser control worked normally before the recent few days. The local version transition was:

    • 2026-09-06 20:59 local: desktop 26.901.2854.0, browser runtime 26.901.22334
    • 2026-09-06 22:00 local: desktop 26.901.6511.0, browser runtime 26.901.51231

    After that update, No ChatGPT browser route is available occurrences increased sharply in the desktop logs and the user-visible timeouts began. Later updates (26.903.8094.0 and now 26.903.9818.0) have not eliminated the problem. This is a temporal correlation, not proof that the update is the root cause.

    Control checks

    • Bundled component versions are aligned; no stale app-package path was found.
    • The native-host manifest and executable exist, the extension origin is allowed, and extension-host.exe is running.
    • Full app restart and REPL reset do not fix it.
    • No registry, proxy, browser-profile, or Codex configuration changes were made during this diagnosis.

    This appears closely related to #44117 and #44500, with the additional observation that direct IAB tab creation can succeed while global inventory remains poisoned by the missing route.

  5. vnforever10-adi commented on Sep 22, 2026

    @vnforever10-adi
    vnforever10-adi
    on Sep 22, 2026 – with ChatGPT Codex Connector

    Additional Windows reproduction — desktop package 26.915.4065.0 (2026-09-22)

    The built-in browser can be opened in the current task, but acquiring its existing public-page tab still times out. Reopening the browser panel did not restore agent access.

    Environment

    • Windows x64, desktop application package OpenAI.Codex 26.915.4065.0 (verified from the installed package).
    • Built-in browser (IAB), not an extension-browser test.
    • Public test URL: https://example.com/ (no authentication or application-specific data).
    • Observation date: 2026-09-22.

    Reproduction observed

    1. Close the built-in browser panel in the affected task, reopen it, and navigate to https://example.com/.
    2. The application reports one tab at that URL. Desktop lifecycle logs confirm that the sidebar was associated with the current task and its webview was created and attached.
    3. Attempt a read-only acquisition of the existing tab: 
      await cua.getTab({ url: "https://example.com/" }, { browser: "iab" });
    4. With a 20-second tool timeout configured, the call returned after approximately 28.5 seconds: 
      js execution timed out; kernel reset, rerun your request
    5. No tab object, page title, or body text was returned. Earlier browser-state discovery had also timed out.

    Sanitized log timeline (UTC)

    • 03:00:51: browser sidebar thread registered; renderer created the webview; runtime attached the browser sidebar webview.
    • 03:01:51.970: one IAB getInfo request completed for the current task.
    • 03:01:51.971: the following getInfo request failed: 
      No ChatGPT browser route is available for browser session <redacted>
    • 03:01:52: browser-use active state was synchronized and the sidebar window was rebound, but the tool still did not return the tab.
    • The browser-control MCP service had previously reported ready.

    The same session-route error also appeared earlier that day, with a successful getInfo between failures. Therefore this is not a claim that the route was permanently absent or that the exact root cause is known. The observations point to session-route/control attachment or response propagation as investigation leads.

    Expected behavior / impact

    An already-open public tab should be readable by the agent. The failure blocks actual browser acceptance testing before any business application is accessed.

    Please advise whether a fixed build or supported recovery procedure is available, and how to distinguish a registered/visible webview from a usable browser-control route.

    No application internals, browser data, or permissions were modified for this diagnosis. No project source, local paths, credentials, task identifiers, complete conversations, screenshots, or raw logs are included in this report.

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