Windows desktop: cua.getState fails with nodeRepl.fetch request failed while built-in browser is visible #45340

Activity

1. 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

   computer-use

   tool-callsIssues related to tool callingIssues related to tool calling

   on Sep 14, 2026
2. github-actions commented on Sep 14, 2026

   

   github-actionsbot

   on Sep 14, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • [Windows app 26.903.8094.0] In-app browser discovery fails with nodeRepl.fetch request failed after cua_repl reset #44117
   • [Windows][Codex App] Browser Use and Computer Use both fail at initialization with nodeRepl.fetch request failed #44500
   • [Windows] IAB route disappears after successful getInfo and persists after full app-data reset #45028

   Powered by Codex Action
3. 793435067lin-rgb commented on Sep 14, 2026

   

   793435067lin-rgb

   on Sep 14, 2026 – with ChatGPT Codex Connector

   Author

   More actions

   Additional diagnostic evidence (sanitized):

   • Running Windows application package path identifies version 26.908.4834.0.
   • Current application logs explicitly report No ChatGPT browser route is available for browser session.
   • Browser sidebar lifecycle logs also show an owner-sync event with a client-new-thread: conversation identifier. All identifiers are omitted here. A connection to the failure is a hypothesis, not a confirmed root cause.
   • Used the supported app navigation tool to navigate to the actual current thread, then reset the CUA kernel and called cua.getState() again. It still failed after approximately 21 seconds.
   • The current log again records the missing-browser-route error after this test.

   No browser storage, credentials or account data were inspected. No application binary or internal routing state was modified.
4. 793435067lin-rgb commented on Sep 14, 2026

   

   793435067lin-rgb

   on Sep 14, 2026 – with ChatGPT Codex Connector

   Author

   More actions

   Verified workaround in the same session, without restarting the desktop app or clearing browser data:

   1. Global cua.getState() fails, but directly selecting the in-app browser via cua.createBrowserTab("iab", localPreviewUrl, {visible:true}) succeeds.
   2. Browser-specific cua.listTabs({browser: returnedBrowserId}) succeeds.
   3. An external dashboard tab was created even though its automatic AX-state read timed out. Reacquiring the observed tab through the documented agent.browsers.get(id).tabs.get(tabId) API and calling tab.playwright.domSnapshot() succeeded.
   4. Existing authenticated dashboard sessions remained usable.

   This narrows the observed failures to global inventory and, separately, an AX-read timeout. It does not prove the underlying implementation root cause. Please retain the issue as open; this is a verified workaround, not an upstream fix.
5. Tokisaki commented on Sep 14, 2026

   

   Tokisaki

   on Sep 14, 2026

   More actions

   Additional reproduction from another affected Windows system (sanitized):

   Environment

   • Codex Desktop 26.908.4834.0
   • Microsoft Windows NT 10.0.26200.0 x64
   • In-app browser enabled; three IAB tabs were visibly open, including a normal HTTPS page

   Observed behavior

   1. cua.getState() returned no apps or browsers and reported:

      {"apps":[],"browsers":[],"errors":["Browsers: Error: nodeRepl.fetch request failed"]}

   2. Resetting the CUA JavaScript runtime and retrying produced the same failure.
   3. Directly calling cua.createBrowserTab("iab", <https-url>, { visible: true }) also failed in this session, so the direct-IAB workaround described above was not available here.
   4. Opening the URL through the Codex panel API returned queued, and navigating back to the current task did not restore browser control.
   5. The desktop log repeatedly recorded:

      No ChatGPT browser route is available for browser session <redacted>
      

   6. Browser lifecycle entries showed the visible tab with ownerRoutePath=/local/<current-task-id>, while its conversationId was client-new-thread:<redacted>. Newly opened IAB tabs were assigned to that same transient conversation rather than the active task.

   The helper process and plugin configuration were present, codex doctor reported the app server initialized and connectivity checks healthy, and the failure occurred before meaningful interaction with the target website. This makes the issue appear site-independent.

   The route/conversation mismatch is an observed correlation, not a confirmed root cause. No credentials, account identifiers, browser storage, full logs, or unredacted task/session IDs are included.
6. ericzhao0825-stack commented on Sep 20, 2026

   

   ericzhao0825-stack

   on Sep 20, 2026 – with ChatGPT Codex Connector

   More actions

   Additional reproduction from another affected Windows 11 system (sanitized).

   Environment:

   • Codex Desktop: 26.915.4065.0
   • Bundled CLI: 0.155.0-alpha.9.2
   • Computer Use plugin: 26.915.31945
   • @oai/sky: 0.7.1
   • Bundled Node: 24.21.0
   • Windows build: 26200

   Observed behavior:

   • Browser discovery fails after ~23.65s with nodeRepl.fetch request failed.
   • Opening a simple public Chrome page fails after ~29.97s with the same error.
   • Desktop logs also contain: No ChatGPT browser route is available.
   • Direct IAB can sometimes read an authenticated tab URL/title and a DOM snapshot (~3.5s), but a subsequent semantic-locator read can still time out at the ~25s ceiling and reset the runtime.
   • The same failure pattern has reproduced across fresh tasks / sessions, so this is not limited to one stale thread.

   Config/runtime inconsistency:

   • The effective config path is the expected %USERPROFILE%\.codex\config.toml.
   • Desktop recognizes the Computer Use configuration section, but the bundled CLI rejects:
     computer_use.windows.always_allowed_app_ids
     as:
     unknown configuration field computer_use.windows.always_allowed_app_ids
   • The Desktop bundle also contains a thread_tools feature override path, while the bundled CLI feature list does not expose thread_tools.

   Package integrity:

   • The official OpenAI MSIX currently available is still 26.915.4065.0.
   • 1,061 relevant runtime/plugin files were compared against the official package and matched by hash.
   • A historical dependency-download problem had later recovered.
   • Because the installed runtime matched the official package, no blind reinstall/repair was performed.

   Network/proxy observations:

   • A system proxy is present; no active TUN was detected.
   • Connectivity differences were observed, but they were not sufficient to prove the proxy is the root cause.

   Local workaround result:

   • A reversible local test based on the bounded request-header/identity wait described in [Windows][Desktop] Browser tab RPCs block on unbounded request-header identity lookup #45014 was attempted only after backing up and hashing the original runtime.
   • The workaround initially appeared to help, but the first subsequent page transition reproduced the control-channel timeout.
   • The original runtime was restored byte-for-byte and the SHA-256 matched the pre-test value.
   • No second patch was stacked.

   This strongly suggests a Windows Codex Desktop Browser/Computer Use runtime or route/session control problem rather than a target-site-specific failure. The exact root cause is still unconfirmed.

   Privacy note: this report intentionally excludes usernames, local absolute paths, task/thread IDs, account IDs, authenticated URLs, cloud resource IDs, credentials, cookies, tokens, project names, and browser history.
7. qihangzhang-272 commented on Sep 24, 2026

   

   qihangzhang-272

   on Sep 24, 2026

   More actions

   Additional reproduction on Windows after a full Codex Desktop restart and in a newly created local task.

   • Windows 11 x64, build 26200; Codex Desktop MSIX 26.917.8451.0; bundled Browser Use release 26.917.62051.
   • await cua.getState() returned no browsers and Browsers: Error: nodeRepl.fetch request failed after about 22 seconds.
   • cua.createBrowserTab("iab", "https://example.com", { visible: true }) timed out after 30 seconds and reset the tool kernel. The desktop log nevertheless recorded the browser webview becoming DOM-ready at https://example.com/.
   • The desktop log first recorded a Browser Use route for the real task ID, then reassigned that route to a client-new-thread placeholder. Subsequent getInfo requests for the real task ID failed with No ChatGPT browser route is available for browser session ....
   • The local HTTP proxy was listening and returned HTTP 200 for https://example.com/. This confirms that the test page was reachable; I have not established whether network conditions can trigger the route mismatch.

   Expected: a newly created local task can enumerate and control its in-app browser tab after an app restart. The route should remain associated with the real task ID once it is known.

   No raw logs, local paths, or task IDs are included here.
8. WxyNeon commented on Sep 26, 2026

   

   WxyNeon

   on Sep 26, 2026

   More actions

   Additional Windows reproduction with separate discovery, tab metadata, and page-control tests (September 26, 2026).

   Environment:

   • Codex Desktop AppX: 26.915.4065.0
   • unified-computer-use component: 26.915.31945
   • Configured CUA Node/REPL files exist, and observed CUA Node/REPL processes use the same runtime directory. No old-runtime mismatch was identified in these checks.

   Observed behavior:

   1. Aggregate cua.getState() fails after approximately 21.8 seconds with nodeRepl.fetch request failed.
   2. A separate cua.listBrowsers() succeeds and discovers both the in-app browser and the Edge extension provider.
   3. The in-app browser initially returns an empty tab list successfully.
   4. Creating https://example.com times out at 30 seconds, but a subsequent separate listTabs call succeeds and returns tab 1, title Example Domain, and https://example.com/. The page was actually created and loaded despite the failed tool call.
   5. Binding that already-loaded tab with cua.getTab still times out after 30 seconds. Separating creation from later attachment did not recover page-state access.
   6. Edge listTabs separately fails after approximately 21.7 seconds. This does not establish that the two providers share the same cause.

   Sanitized desktop-log observations:

   • Earlier calls for the affected task: No ChatGPT browser route is available for browser session [redacted].
   • After a desktop restart, another public-page test successfully attached the sidebar guest and mapped the page to a tab. executeCdp:Emulation.setFocusEmulationEnabled then failed with No target available in sendDebuggerCommand. A later getInfo request succeeded.
   • The later example.com test also successfully attached and mapped its page before control timed out.

   Please distinguish successful page creation and metadata enumeration from successful debugger/page-control attachment. The generic fetch error masks these differences. We have not established whether the cause is target initialization, session-route binding, request-policy initialization, or another transport dependency. Proxy causation has not been demonstrated by these tests.

   Could maintainers provide a supported diagnostic or fixed build for this behavior? No application patch, proxy change, or security-policy bypass was applied during these tests. No credentials, private page content, account identifiers, session IDs, or raw logs are included.
9. ejdiliscia commented on Oct 8, 2026

   

   ejdiliscia

   on Oct 8, 2026

   More actions

   I can reproduce a closely related Browser Use failure on ChatGPT Desktop for Windows. I investigated the local logs and found additional evidence that may help identify the underlying issue.

   Environment

   • ChatGPT Desktop internal release: 26.1002.52244
   • Windows package: OpenAI.Codex 26.1002.7124.0
   • Codex: 0.162.0-alpha.2
   • cua_node: 0.0.29/20261003001300-807782c586fc

   Reproduction

   Both operations time out:

   await cua.getState();

   await cua.createBrowserTab("iab", "https://example.com", { visible: true });

   Both return:

   js execution timed out; kernel reset, rerun your request
   

   The latest recorded attempts took approximately 30 seconds. The failure occurs in fresh Work sessions and when testing Browser Use directly through Codex.

   Evidence from local logs

   The backend is not completely unresponsive.

   During the createBrowserTab attempt on October 8, 2026, the logs show the following sequence. All times below are UTC−3:

   Time	Event
   11:24:15	Browser tab creation requested.
   11:24:16	No ChatGPT browser route is available for browser session
   11:24:18	Browser view attached, tab created, and debugger registered.
   11:24:19	The requested page reached dom-ready.
   11:24:45	The operation timed out without returning a result.

   The browser route error also appears repeatedly during failed getState() calls.

   Logs reference both the actual chat session and a provisional client-new-thread route. I cannot confirm whether this difference causes the timeout. Successful backend operations also appear alongside the route errors.

   Computer Use comparison

   Windows desktop Computer Use works through @oai/sky:

   • sky.list_windows() succeeds in approximately 1.2 seconds.
   • Both Work and direct Codex sessions can interact with Notepad.
   • Browser Use through cua_repl continues to fail.

   Switching the Windows sandbox to unelevated restored the @oai/sky operations but did not resolve the Browser Use timeouts.

   Possible area to investigate

   The evidence points toward Browser session routing (browser-session-registry / browser-use-iab-api) or an operation that remains pending after navigation, such as accessibility state retrieval or final response delivery.

   The logs confirm that the browser page loads, but they do not identify the exact operation that remains pending. This is an investigation lead, not a confirmed root cause.

   The investigation was read-only. I have not modified application files or attempted an unsupported repair. I can provide additional sanitized diagnostic information if helpful.