[Windows][Desktop] Built-in browser can list tabs, but page reads time out and the Browser session route is lost #48360

Activity

1. github-actions

   changed the title [-][Windows][Desktop] 内置浏览器可列出标签，但读取页面超时并丢失 Browser session route[/-] [+][Windows][Desktop] Built-in browser can list tabs, but page reads time out and the Browser session route is lost[/+] on Sep 26, 2026
2. github-actions commented on Sep 26, 2026

   

   github-actionsbot

   on Sep 26, 2026 – with GitHub Actions

   Contributor

   More actions

   English translation:

   Issue overview

   Users can manually open regular web pages in the built-in browser in the Windows Codex desktop app, but Browser Use intermittently or persistently fails to read pages. Browser lists/tab lists sometimes return successfully; getting a tab, reading a page's accessibility state, or reading the state after creating a tab times out after approximately 15–30 seconds. During the same request, the desktop logs repeatedly report No ChatGPT browser route is available for browser session <已脱敏>.

   This failure reproduces on the public page https://example.com/, so it is not specific to a particular business website.

   Environment

   • Windows x64, OS version 10.0.26100
   • Application version in the Codex desktop logs: 26.917.71314
   • Version shown in the Windows application package path: 26.917.9434.0
   • Running natively on Windows; confirmed WSL mixed runtime = FALSE
   • Built-in browser (IAB); the cua_node runtime, node_repl binary, and MCP startup all pass basic checks

   Minimal reproduction

   1. Open the built-in browser in the Codex desktop app and navigate to https://example.com/.
   2. Ask Codex to read only the current page title, or call cua.getTab({ url: "https://example.com/" }, { browser: "iab" }).
   3. The request times out after approximately 15–30 seconds with js execution timed out; kernel reset, rerun your request; sometimes the state shows apps=[], browsers=[], or nodeRepl.fetch request failed.
   4. In some sessions after restarting, cua.listTabs({ browser: "iab" }) can quickly list the Example Domain tab, but getting that tab to read the page content still times out. A call to create a test tab also timed out, but a subsequent tab list showed that it had actually been created.
   5. Application logs from the same period continue to show browser route errors.

   Minimal A/B checks completed

   • Reading example.com succeeded once, then failed again during the same type of operation: intermittent.
   • Both the business website and example.com have failed: not site-specific.
   • After switching to another US VPN endpoint, reading the same example.com page still failed.
   • After keeping that endpoint and fully restarting Codex, tab discovery partially recovered, but reading page content still failed.
   • Creating a new Codex task did not resolve the issue either (the user had already tested this).
   • Manually loading web pages in the built-in browser generally works normally.
   • codex doctor previously reported that WebSocket and some HTTP Providers were unreachable; desktop logs also recorded net::ERR_PROXY_CONNECTION_FAILED. These indicate that the network/proxy may contribute to triggering the issue, but the route errors that persist after switching endpoints and restarting cannot be attributed solely to the VPN.

   Redacted log excerpts

   Only error types and observed timestamps are retained below; session IDs, accounts, URL parameters, and local paths are omitted:

   2026-09-23 22:07:04 CST  net::ERR_PROXY_CONNECTION_FAILED
   2026-09-23 22:09:36 CST  [browser-use-iab-api] IAB_LIFECYCLE iab backend info request failed
                              No ChatGPT browser route is available for browser session <redacted>
   2026-09-26 12:47:45 CST  No ChatGPT browser route is available for browser session <redacted>
   2026-09-26 12:55:50 CST  No ChatGPT browser route is available for browser session <redacted>
   

   Expected and actual behavior

   Expected: When the built-in browser has example.com open, Browser Use should be able to get that tab and read its title/page state. If the route becomes invalid, it should return an actionable component error, rather than timing out for a long period or producing hidden test tabs that were actually created despite the call failing.

   Actual: The user can see the web page, but automation frequently times out. Tab discovery and reading tab content may produce inconsistent results.

   Investigation request

   Please check IAB route registration, session ID binding, tab RPC/readiness, and cleanup logic after timeouts in the Windows desktop app, and clarify whether there is a supported session recovery method. In particular, please distinguish proxy/WebSocket interruptions from loss of Electron/native pipe session bindings. The user has not reinstalled the app, deleted .codex, deleted the runtime, or cleared all caches.

   Related public reports: #45028, #47123, #44364.

   👍React with 👍1Reacted by mkenton3
3. github-actions commented on Sep 26, 2026

   

   github-actionsbot

   on Sep 26, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Navigation and page loading in the built-in Windows browser keep timing out. #47477
   • [Desktop][Browser Use] No ChatGPT browser route prevents Chrome and built-in browser tab discovery #47270
   • macOS: Chrome browser control times out with “No ChatGPT browser route is available” #48322
   • [Windows][Desktop] Chrome discovered but list/open tabs fail with nodeRepl.fetch on 26.915.4065.0 #47732
   • [Windows][Desktop] Browser session discovery still fails with nodeRepl.fetch after clean IPC rebuild #47123

   Powered by Codex Action
4. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   browser

   connectivityIssues involving networking or endpoint connectivity problems (disconnections)Issues involving networking or endpoint connectivity problems (disconnections)

   on Sep 26, 2026
5. chenchunxin46-creator commented on Oct 17, 2026

   

   chenchunxin46-creator

   on Oct 17, 2026 – with ChatGPT Codex Connector

   More actions

   Additional reproduction on Windows / October 17, 2026

   The built-in browser issue remains reproducible on a newer production build. Adding measured timings and sanitized diagnostics to this existing report.

   Environment

   • Windows 10 Pro, build 19045, x64.
   • Updater-reported installedVersion: 26.1013.40934, installedBuildVersion: 20770, release channel: prod; update check reported up_to_date.
   • Installed MSIX package version: OpenAI.Codex_26.1013.4894.0_x64 (reported separately because this differs from the updater's version string).
   • Codex built-in browser (IAB), using the supported CUA browser API.

   Observed behavior

   • The user can see the loaded page. Browser/tab discovery and cached URL metadata can return quickly; screenshots can work while DOM/accessibility reads remain slow.
   • This occurs on a public Douyin search page and on https://example.com/, so the symptom is not limited to the business website.
   • One measurement was approximately 10 seconds to obtain the tab handle plus 21.4 seconds for a page read. A combined call exceeded the default 30-second outer timeout and returned:

     js execution timed out; kernel reset, rerun your request
     

   • Timings are variable: a newly created tab once read in about 434 ms, then later reads returned to around 21 seconds. Other combined calls took longer.
   • Splitting connection/navigation/read steps and using a 60-second outer timeout allowed some reads and an input/readback check to succeed. This is a partial workaround, not a latency fix. Earlier agent attempts with 12–20-second outer limits also contributed to avoidable timeouts.
   • A successful click API response was not sufficient to prove the expected filter UI opened; interaction reliability remains unconfirmed.

   Recovery attempts and results

   1. Fully exited and restarted Codex; process start time changed. The issue persisted.
   2. Used Windows Settings Repair (not Reset), then fully restarted Codex again. A subsequent DOM read still took approximately 21.4 seconds (about 31.4 seconds total tool wall time including connection).
   3. Closed the original restored tab and recreated the public search page through the supported browser API. This did not remove the long read delay.
   4. Preserved/reused valid tab handles and separated operations instead of repeatedly creating new tabs.

   Sanitized concurrent diagnostics

   [browser-use-iab-api]
   No ChatGPT browser route is available for browser session <redacted>
   
   [tpp-local-executor] Local Work executor startup failed
   errorCode=UNKNOWN
   errorMessage="UNKNOWN: unknown error, copyfile '<WindowsApps>/OpenAI.Codex_<version>/app/resources/plugins/openai-bundled/plugins/codex-app-tools/.codex-plugin/plugin.json' -> '<UserProfile>/AppData/Roaming/Codex/web/Codex/executor-plugins/codex-app-tools/.codex-plugin/plugin.json'"
   

   The executor copy failure retried repeatedly and was still present after Windows Repair and the subsequent restart. Logs also showed failures copying a bundled browser plugin into a staging directory.

   A narrow independent file-copy test found:

   • The source bundled manifest had the Windows Encrypted attribute.
   • Bundled Node copyFileSync failed with UNKNOWN.
   • Reading the bytes and writing them to a diagnostic output file succeeded, with matching SHA-256.
   • A generated-cache-only manifest copy did not resolve executor startup: the next application retry removed/recreated the target and failed again.

   There was also an observed mismatch between a temporary client-new-thread:<redacted> browser/sidebar identifier and a concrete local task route. Neither the identifier mismatch nor the plugin copy failure has been established as the cause of the browser latency. They are correlated evidence for investigation, not a confirmed root cause.

   Related copy/materialization reports: #50862, #51218. Related route report: #47270.

   Requested investigation
   Please investigate IAB route binding/recovery, tab read RPC latency, and whether repeated executor/plugin materialization failures can affect browser operations. A supported recovery or fix would be helpful: repeated full restarts and Windows Repair did not resolve this case. Raising the outer timeout should not be treated as a completed product fix.

   No raw logs, private chat content, local usernames, credentials, or session identifiers are attached.
6. 4ky4k947gb-cpu commented on Oct 17, 2026

   

   4ky4k947gb-cpu

   on Oct 17, 2026 – with ChatGPT Codex Connector

   More actions

   Additional Windows reproduction: app hang after browser-route / IPC failures

   Environment:

   • Windows x64, OS version 10.0.26200.
   • Installed MSIX package: OpenAI.Codex_26.1013.4894.0_x64.
   • Executable: ChatGPT.exe; executable version 155.0.8059.80. This is not the updater-reported application version.

   Observed on October 18, 2026 (Asia/Taipei):

   • The supported in-app browser client could sometimes list a tab, but navigation / page reads timed out.
   • Local application logs recorded write EPIPE and No ChatGPT browser route is available for browser session .
   • A later log recorded Conversation state not found for .
   • Windows recorded ChatGPT.exe Application Hang (event 1002) at 00:23 and 00:35. The user regained mouse control after closing the affected application.
   • During an earlier failed browser attempt, the local test server remained responsive: the HTML route returned HTTP 200 and an application API returned 86,021 bytes in about 140 ms. This verifies server responsiveness only, not successful browser rendering.
   • The local test server is now intentionally stopped. Further browser reproduction was stopped after the UI hang.

   Limits:
   The exact causal chain between browser-route loss, IPC failure, conversation-state error and UI hang is unconfirmed. Post-recovery free memory is not evidence of memory availability at the exact hang instant. GPU/Audio process termination logged during shutdown is not proof of a GPU fault. Longer-timeout workarounds reported by others have not been retested here because the desktop had become unresponsive.

   Request:
   Please advise a supported recovery or fixed Windows release for browser-route loss, and whether the associated application hang needs a separate issue. Recovery must preserve existing chats, local source, browser data and permissions. No cache/profile deletion, application-code modification or security-check bypass was performed.

   Privacy: This comment omits account details, subscription, chat/session/process/pipe identifiers, private URLs, usernames, local paths, business names, payment data, credentials, screenshots and raw logs.

   Related existing report: #48360