[Windows 11][26.908.9136.0] Chrome backend is discoverable but tab operations fail with nodeRepl.fetch request failed
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 125k
- Forks
- 19.4k
- PR merge metrics
- PR metrics pending
Description
What version of the Codex App are you using (From “About Codex” dialog)?
Codex Desktop 26.908.9136.0Bundled Chrome plugin: 26.908.70816Bundled Computer Use / unified computer-use plugin: 26.908.70816
What subscription do you have?
Codex Plus
What platform is your computer?
Windows 11 x64 (10.0.26200)Google Chrome Stable 153.0.8010.37ChatGPT Chrome extension 1.26.901.11451Extension ID: hehggadaopoacecdllhhajmbjkdcmajg
What issue are you seeing?
The Chrome plugin, Chrome extension, Native Messaging registration, manifest, and host executable are present. The Chrome Native Messaging host starts successfully, and the browser API can return a Chrome browser ID. However, the extension-backed control channel is not usable: listing tabs or creating a controlled Chrome tab fails with nodeRepl.fetch request failed after approximately 20 seconds.
The in-app browser (iab) remains usable through a direct-selection workaround, so the bundled browser runtime and Playwright DOM path are not completely unavailable. The failure appears specific to the Chrome extension-backed session/transport path.
What steps can reproduce the bug?
- Install and enable the bundled Chrome and Computer Use plugins in Codex Desktop.
- Install and enable the official ChatGPT Chrome extension in Chrome's Default profile.
- Confirm that the extension and Native Messaging host are connected.
- Fully restart Chrome and Codex Desktop.
- Start a fresh local Codex task.
- Select the Chrome backend and list tabs.
- Observe that selecting the backend can return a browser ID, but the first tab operation fails.
Observed minimal behavior:
agent.browsers.get("chrome") -> returns a browser object / browser ID
browser.tabs.list() -> nodeRepl.fetch request failed
The higher-level path also fails:
cua.createBrowserTab("chrome", "https://example.com", ...)
-> nodeRepl.fetch request failed
What is the expected behavior?
After the Chrome extension and Native Messaging host connect, Codex should be able to list existing tabs, create an agent-controlled tab, read page state, and interact with the page.
If the Chrome transport cannot establish a usable session, the tool should report which layer failed rather than returning a generic fetch error after a timeout.
Additional information
Diagnostics verified without reading browser databases, cookies, history, passwords, or authenticated page content:
- Native Messaging registration and manifest are present and point to an existing bundled host executable.
- The manifest allows the installed stable extension origin.
- The native host starts as a child of Chrome's Native Messaging process chain.
- A full Chrome restart created new Chrome and native-host processes, but the failure remained.
- No
.agent-browserChrome process or autostart entry was present. CUA_REPL_ENABLED_SURFACES=browseris already configured.- No stale
setupCUA(...)banner was found.
Control test: global browser inventory may also fail, but directly selecting the in-app browser works. If automatic AX-state collection times out, reacquiring the observed in-app tab and calling tab.playwright.domSnapshot() succeeds. The equivalent Chrome tab operation remains unusable.
Related issues: #22849, #21908, #27962, #38134, #41408, #45047.
Privacy: this report excludes usernames, absolute user paths, task/thread IDs, dynamic ports, tokens, browser history, tab titles, authenticated URLs, cookies, local storage, and account identifiers.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the Chrome path with agent.browsers.get("chrome"), browser.tabs.list(), and cua.createBrowserTab(), then compare it with the working in-app browser path. Read related issues #22849, #21908, #27962, #38134, #41408, and #45047 while tracing the extension-backed session after the browser ID is returned. Done means Chrome tabs can be listed and created, or the failing transport layer is reported without a generic timeout.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- playwright, rust
- Domain
- desktop, devtools
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100