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

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

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

   

   github-actionsbot

   on Sep 11, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Windows: Chrome control fails with nodeRepl.fetch request failed #44135
   • [Windows][Codex App] Browser Use and Computer Use both fail at initialization with nodeRepl.fetch request failed #44500
   • [macOS, 26.901.51231] Chrome is discovered, but browser-control calls fail with nodeRepl.fetch request failed #43787
   • [macOS, 26.903.61454, Edge] Extension discovery succeeds but tab enumeration times out, including in a fresh task #44390
   • [Codex app][Windows] Chrome control fails without TUN; verified cua_repl launch.mjs proxy workaround #44364

   Powered by Codex Action
3. IXH10 commented on Sep 11, 2026

   

   IXH10

   on Sep 11, 2026 – with ChatGPT Codex Connector

   More actions

   Additional reproduction with Microsoft Edge on Windows, observed on September 11, 2026.

   Environment

   • Codex desktop client: 26.903.71938
   • Windows package: 26.903.9818.0_x64
   • Bundled CLI version observed in diagnostics: 0.153.4
   • Browser extension: 1.26.901.11451
   • Browser/CUA plugin runtime: 26.903.71938

   Reproduction

   Ask Codex to read the currently open Edge tabs (original prompt: “请读取 Edge 当前打开的标签页，测试浏览器连接。”).

   In the browser runtime available during this reproduction:

   1. var browser = await cua.getBrowser({ id: "edge" }); succeeds and selects Edge, type extension.
   2. await browser.user.openTabs() fails with nodeRepl.fetch request failed.
   3. cua.listTabs({browser:"edge"}) fails with the same error.
   4. cua.getState() returns:

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

   No tab titles or URLs can be read. The failure persists across retries, a CUA JavaScript runtime reset, and desktop restarts. Earlier calls failed after roughly 22–32 seconds; the most recent attempts failed after roughly 4.5–4.8 seconds.

   Checks completed

   • Edge is running.
   • Bundled extension diagnostics report the extension installed, enabled and registered, with no disabled state.
   • Native-host manifest/registry diagnostics pass when run outside the restricted shell sandbox.
   • The browser-launched extension-host.exe process is running.

   Network context and limits of the diagnosis

   Windows system proxy is enabled through a local HTTP proxy. HTTP_PROXY, HTTPS_PROXY, ALL_PROXY and NO_PROXY were absent in the inspected Codex and node_repl process environments.

   An unauthenticated curl probe to https://chatgpt.com/backend-api/aura/identity timed out when explicitly bypassing the proxy; the same probe through the configured proxy returned HTTP 401. This only establishes a difference in endpoint reachability, not the cause of the authenticated browser-runtime failure. A successful launch with proxy variables inherited by the actual failing process has not been verified, and a clean-profile test has not been completed.

   Expected: enumerate Edge's existing tabs, or return an actionable error identifying the failed component and underlying network/transport cause.

   Actual: Edge selection succeeds, but tab enumeration only returns the generic nodeRepl.fetch request failed. The root cause remains unconfirmed; this report does not establish a Windows OS defect or prove that proxy handling is responsible.

   This comment contains a sanitized diagnostic summary; raw logs, private paths, account/session identifiers and browsing content are omitted.
4. Jackbshf commented on Sep 11, 2026

   

   Jackbshf

   on Sep 11, 2026 – with ChatGPT Codex Connector

   More actions

   Additional Windows + Microsoft Edge reproduction (September 12, 2026, UTC+08:00), with user-authorized sanitized reporting.

   Environment observed locally: Windows build 10.0.26200; bundled browser / unified-computer-use runtime 26.903.71938. Edge extension installation/enabled state and native-host manifest checks passed.

   Expected: enumerate Edge's existing tabs and operate the selected tab through the extension.

   Actual: browser discovery identifies Edge (type extension), but tab enumeration and session naming fail after approximately 21 seconds with nodeRepl.fetch request failed. The same failure was observed through both the unified browser tool and the bundled browser-client entry point. Repeated application restarts have not resolved the user's reported problem. No browser-control recovery has been verified.

   A local HTTP proxy is configured in Windows. An unauthenticated connectivity comparison timed out directly and returned a Cloudflare HTTP 403 through the existing proxy; this is not evidence of successful authentication. Adding HTTP_PROXY/HTTPS_PROXY/NO_PROXY only to the legacy [mcp_servers.node_repl.env] did not produce a successful browser-control retest. We have not established whether those settings reached the actual failing process. We are examining the active CUA launcher in light of #44364, without assuming proxy handling is the root cause.

   Separately, the user reports repeated visible refreshing in the in-app browser. This symptom has not been instrumented and is not claimed to share a cause with the Edge RPC failure.

   Could maintainers confirm whether there is a supported fix/version or a stable proxy-environment override for the active CUA runtime, and which sanitized diagnostic would reveal the underlying transport error? Please distinguish this from extension discovery, which succeeds.

   No raw logs, session IDs, private URLs, account details, local user paths, documents, or conversation transcript are included.
5. lijialu6860 commented on Sep 12, 2026

   

   lijialu6860

   on Sep 12, 2026

   More actions

   Codex Desktop 26.908 on Windows: browser-control RPC timeouts and stale IAB routes

   Summary

   Codex Desktop can load a page in the Codex In-app Browser, and the browser discovery API can sometimes find the available backends. However, browser-control operations then fail or hang:

   • IAB URL/title reads may work, but DOM/accessibility reads time out.
   • Edge extension tabs.list, tabs.new, and tabs.selected time out.
   • Global tab lookup also times out.
   • The native Sky fallback reports Trusted RPC service is not configured: sky.

   The behavior is reproducible across new and existing tasks and is not specific to Fab or to example.com.

   Environment

   • Windows 11 Pro, build 26200
   • Codex Desktop AppX: 26.908.4834.0
   • Codex browser/CUA runtime: 26.908.40834
   • Microsoft Edge: 152.0.4191.66
   • Edge profile: Profile 2
   • Local proxy: 127.0.0.1:7897 through Clash Verge
   • Reproduction date: 2026-09-12 (Asia/Shanghai)

   Minimal reproduction

   1. Open Codex Desktop and use a new or existing task.

   2. Open the Codex In-app Browser and navigate to https://example.com/.

   3. Run:

      await cua.listBrowsers()

      This discovers the Edge extension backend (id 2) and the Codex In-app Browser backend (id 1).

   4. Test the IAB backend:

      let browser = await cua.getBrowser({id: "1"})
      await browser.tabs.list()
      let tab = await browser.tabs.get("1")
      await tab.url()
      await tab.title()

      This succeeds and returns https://example.com/ and Example Domain.

   5. On the same tab, request a DOM snapshot or accessibility tree. The request times out after approximately 15 seconds and resets the CUA REPL kernel.

   6. Test the Edge backend:

      let edge = await cua.getBrowser({id: "2"})
      await edge.tabs.new()
      await edge.tabs.list()
      await edge.tabs.selected()

      These operations time out during RPC communication. The common error is:

      nodeRepl.fetch request failed
      

   7. The global tab route also times out:

      await cua.getTab("1", {browser: "1"})

   8. Testing the native Sky/computer-use fallback returns:

      Trusted RPC service is not configured: sky
      

   Result matrix

   Operation	Result
   cua.listBrowsers()	Usually succeeds
   IAB tabs.list()	Succeeds
   IAB url() / title()	Succeeds
   IAB DOM snapshot / AX read	Timeout; CUA kernel reset
   Edge tabs.new()	RPC timeout
   Edge tabs.list()	RPC timeout
   Edge tabs.selected()	RPC timeout
   Global cua.getTab()	RPC timeout
   Sky/native fallback	Trusted service error

   cua.getState() has also intermittently returned an empty browser list with Browsers: Error: nodeRepl.fetch request failed, while the direct cua.listBrowsers() call still discovers both backends.

   Relevant configuration evidence

   The active unified-computer-use manifest contains the equivalent of:

   CUA_REPL_ENABLED_SURFACES=browser
   NODE_REPL_TRUSTED_SERVICES={"browser":"@oai/browser-desktop/service"}
   

   The root Codex configuration contains a Sky entry, but it is not propagated to the active cua_repl process. The installed @oai/sky runtime requires a trusted Sky RPC service.

   Log evidence

   Codex Desktop logs show repeated IAB backend startup events. They also show getInfo requests made with session IDs that have already ended, followed by:

   No ChatGPT browser route is available for browser session <session-id>
   

   This appears consistent with a stale session reference or a race between page-state creation, route registration, route lookup, and route cleanup. Multiple codex-browser-use-* named pipes are created during the process, but I did not delete them or terminate processes.

   Checks already performed

   • Edge is running.
   • The browser extension is installed and enabled.
   • The Native Messaging host manifest is valid.
   • Relevant Chrome/Edge fallback registry state was checked.
   • Windows services, AppX package information, processes, ports, and event logs were checked.
   • WS/WSS proxy variables were temporarily isolated and then restored; the failure remained.
   • No registry, Windows service, AppX, process, session-file, or named-pipe deletion was performed.
   • No permanent manual modification was made to the managed plugin cache.

   Expected behavior

   After browser discovery succeeds, I should be able to consistently enumerate or create a tab, select it, read its URL/title/DOM/accessibility state, and perform browser actions through either IAB or the Edge extension without RPC timeouts or stale-route errors.

   Likely areas to investigate

   1. Make IAB route creation, registration, lookup, and cleanup an atomic or explicitly validated state machine.
   2. Immediately invalidate ended session IDs and reject later getInfo requests for them.
   3. Prevent duplicate IAB backend startup for the same task/session, or define a clear primary-route and cleanup policy.
   4. Investigate why Edge tab RPC calls time out after backend discovery succeeds.
   5. Ensure all browser APIs use the same route/session registry.
   6. If Windows Sky/native computer use is supported, inject both the Sky trusted service and the required computer-use surface into the active CUA manifest.
   7. Add privacy-safe diagnostics for backend type, session ID, route state, and pipe lifetime.
   8. Add Windows regression tests for IAB, Edge extension control, new tasks, restored tasks, and stale-session cleanup.

   Maintainer request

   Could you confirm whether this is a known issue in the 26.908 Desktop/CUA runtime, and advise whether a test build or supported manifest regeneration is available? I can provide one redacted diagnostic log bundle privately if needed.

   Privacy note

   The report intentionally omits account identifiers, cookies, tokens, full browsing history, and unredacted local paths. Any attached logs should be reviewed and redacted before public posting.
6. louisamazon409-max commented on Sep 23, 2026

   

   louisamazon409-max

   on Sep 23, 2026 – with ChatGPT Codex Connector

   More actions

   Additional sanitized Windows reproduction on September 23, 2026.

   • Codex desktop package: 26.917.6896.0; official Chrome extension: 1.26.901.11451.
   • The Chrome extension browser is discovered, and its side panel loads. The browser-launched native extension-host.exe is running; native-host registration and loopback checks pass.
   • However, listing existing Chrome tabs consistently fails after about 21 seconds with Error: nodeRepl.fetch request failed. Directly targeting a user-mentioned existing tab fails the same way. No real Chrome tab title, URL, or page content has been read.
   • The built-in browser's tabs.list() succeeds quickly in the same session. A separate new Codex task also reproduced the Chrome tab failure.
   • The extension host's child Codex backend binary matches the desktop backend binary by SHA-256, so an obvious stale-binary mismatch was not found.
   • A local proxy is active, but the ordinary desktop logs did not expose the failed authenticated browser request's URL/status or the lower-level timeout source. A brief manually enabled TUN test interrupted the Codex connection, so Chrome behavior while TUN was enabled was not verified. Proxy routing is therefore not claimed as the root cause.

   Could maintainers provide a supported diagnostic that identifies the failing browser-control request/transport stage, or a confirmed fix for this desktop version? Please distinguish browser discovery from successful tab RPC.

   No private URLs, customer data, account/session/extension IDs, local paths, credentials, screenshots, or raw logs are included.
7. kikuchanhxm commented on Sep 24, 2026

   

   kikuchanhxm

   on Sep 24, 2026 – with ChatGPT Codex Connector

   More actions

   I’m seeing the same issue on Windows and wanted to add a reproducible workaround that may help narrow down the cause.

   Feedback ID: 01a0cd5b-2cf2-71e0-8b0a-211b47702527

   Original symptoms

   • Codex Browser Use could not read my open Chrome tabs.
   • The Chrome extension was installed and enabled.
   • chrome.user.openTabs() consistently failed with nodeRepl.fetch request failed after about 20 seconds.
   • Reinstalling the Browser plugin, restarting Codex Desktop, updating Codex, and starting a fresh Chrome session did not help.
   • Diagnostics confirmed that Chrome was running, the extension was enabled, and the native messaging manifest / registry entry were correct.
   • The native messaging host process started when the request was made, but no tab list was returned.
   • Chrome extension version: 1.26.901.11451_0.

   What fixed it
   I use Clash Verge on Windows. When Clash Verge was running in System Proxy mode, Browser Use failed as described above. After switching Clash Verge from System Proxy mode to TUN mode, chrome.user.openTabs() immediately started working again and Codex could read my open tabs normally.

   This makes it look like the Chrome extension / native messaging setup itself was healthy, and that the failure occurs in the network path used by Codex Browser Use after the native messaging host starts. It may be worth checking whether one of the Browser Use / Node / helper processes on Windows does not inherit or respect the Windows system proxy correctly, while TUN mode works because it captures that traffic at the network layer.