Repository navigation
Codex Chrome Browser Control Failure #45006
Description
What version of the Codex App are you using (From “About Codex” dialog)?
Version 26.908.40834
What subscription do you have?
Pro
What platform is your computer?
Darwin 25.5.0 arm64 arm
What issue are you seeing?
Codex cannot control the system-installed Chrome browser because the browser-provider discovery layer fails.
Chrome is running normally, and the node_repl service starts successfully. However, browser discovery requests hang and time out after 30 seconds.
What steps can reproduce the bug?
Codex Chrome Browser Control Failure
Summary
Codex cannot control the system-installed Chrome browser because the browser-provider discovery layer fails.
Chrome is running normally, and the node_repl service starts successfully. However, browser discovery requests hang and time out after 30 seconds.
Evidence
The local logs show that node_repl starts successfully:
server_name=node_repl
Service initialized as client
Browser-related calls then time out:
node_repl js execution timed out
timeout_ms=30000
The failing calls include:
cua.getState()
cua.listTabs({browser: ""})
cua.createBrowserTab("", "")The empty browser identifier is significant:
browser: ""This indicates that Codex did not discover or register the Chrome browser backend.
Failure Chain
node_repl starts successfully
↓
cua runtime starts
↓
Chrome browser-provider discovery hangs
↓
30-second timeout
↓
browsers: []
Environment
Operating system: macOS
Architecture: Apple Silicon / aarch64
Codex Desktop: 26.908.40834
Chrome: System-installed Google Chrome
Chrome profile: Default
What Is Not Causing the Problem
The failure does not appear to be caused by:
- Chrome not running;
- The Chrome Default profile;
- The localhost editor;
- A missing
node_replexecutable; - The
.sb3project files.
Likely Root Cause
The likely cause is a Codex Desktop browser-provider registration or discovery regression.
The failure occurs after node_repl has started, when Codex attempts to discover or communicate with the Chrome browser provider.
This is consistent with the public issue:
Local Log Location
The relevant log database is:
/Users/XXXXX/.codex/logs_2.sqlite
The relevant log query is:
sqlite3 -noheader ~/.codex/logs_2.sqlite \\
"select datetime(ts,'unixepoch','localtime') || ' | ' || level || ' | ' ||
substr(feedback_log_body,1,1600)
from logs
where feedback_log_body like '%node_repl%'
order by ts desc limit 12;"Expected Behavior
Codex should:
- Discover the connected Chrome browser backend.
- Return the available Chrome tabs.
- Allow browser operations such as navigation and DOM inspection.
Actual Behavior
Codex:
- Starts
node_repl. - Fails to discover a usable Chrome browser backend.
- Calls the browser API with an empty browser identifier.
- Times out after 30 seconds.
- Returns an empty browser list:
browsers: []
Conclusion
The Chrome process and extension appear to be available, but Codex Desktop fails to register or discover the Chrome browser backend. The resulting nodeRepl.fetch request failed error is a Codex browser-provider/runtime integration issue rather than a Chrome or website issue.
What is the expected behavior?
Codex Chrome Browser Control Failure
Summary
Codex cannot control the system-installed Chrome browser because the browser-provider discovery layer fails.
Chrome is running normally, and the node_repl service starts successfully. However, browser discovery requests hang and time out after 30 seconds.
Evidence
The local logs show that node_repl starts successfully:
server_name=node_repl
Service initialized as client
Browser-related calls then time out:
node_repl js execution timed out
timeout_ms=30000
The failing calls include:
cua.getState()
cua.listTabs({browser: ""})
cua.createBrowserTab("", "")The empty browser identifier is significant:
browser: ""This indicates that Codex did not discover or register the Chrome browser backend.
Failure Chain
node_repl starts successfully
↓
cua runtime starts
↓
Chrome browser-provider discovery hangs
↓
30-second timeout
↓
browsers: []
Environment
Operating system: macOS
Architecture: Apple Silicon / aarch64
Codex Desktop: 26.908.40834
Chrome: System-installed Google Chrome
Chrome profile: Default
What Is Not Causing the Problem
The failure does not appear to be caused by:
- Chrome not running;
- The Chrome Default profile;
- The localhost editor;
- A missing
node_replexecutable; - The
.sb3project files.
Likely Root Cause
The likely cause is a Codex Desktop browser-provider registration or discovery regression.
The failure occurs after node_repl has started, when Codex attempts to discover or communicate with the Chrome browser provider.
This is consistent with the public issue:
Local Log Location
The relevant log database is:
/Users/XXXXX/.codex/logs_2.sqlite
The relevant log query is:
sqlite3 -noheader ~/.codex/logs_2.sqlite \\
"select datetime(ts,'unixepoch','localtime') || ' | ' || level || ' | ' ||
substr(feedback_log_body,1,1600)
from logs
where feedback_log_body like '%node_repl%'
order by ts desc limit 12;"Expected Behavior
Codex should:
- Discover the connected Chrome browser backend.
- Return the available Chrome tabs.
- Allow browser operations such as navigation and DOM inspection.
Actual Behavior
Codex:
- Starts
node_repl. - Fails to discover a usable Chrome browser backend.
- Calls the browser API with an empty browser identifier.
- Times out after 30 seconds.
- Returns an empty browser list:
browsers: []
Conclusion
The Chrome process and extension appear to be available, but Codex Desktop fails to register or discover the Chrome browser backend. The resulting nodeRepl.fetch request failed error is a Codex browser-provider/runtime integration issue rather than a Chrome or website issue.
Additional information
No response
Activity
github-actions commentedon Sep 12, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
nodeRepl.fetch request failed#44500Powered by Codex Action
a854008884-ship-it commentedon Sep 15, 2026
I can reproduce the same issue on ChatGPT Desktop 26.908.70816 on macOS / Apple Silicon.
cua.getState() consistently times out with:
js execution timed out; kernel reset, rerun your request
Additional observations:
The in-app browser itself can visibly open webpages normally.
cua.getState() fails even before navigating to a webpage.
The issue persists after a full Mac reboot.
I reproduced it in a completely unrelated new Codex project, so it is not project-specific.
The problem started after updating the desktop app on September 15, 2026.
This strongly appears to be a Computer Use / browser automation control-layer regression rather than a website or project issue.
yuqingzhijie commentedon Sep 23, 2026
01a0c8a6-ee70-7c11-b1e2-d4410d6e79c4
yuqingzhijie commentedon Sep 23, 2026
Title
@Chromeregression since 26.903.61454: native pipe rejects peers withmissing-code-signing-identityBody
After the automatic update to
26.903.61454on 2026-09-09, the app began enabling packaged peer authorization:Every subsequent desktop version tested produces:
Reproduction
Run in a Codex task:
The Chrome extension and native host are detected, but the request times out after 30 seconds with:
@Browserworks normally; only the external Chrome provider fails.Verified
node_repl, and native host signatures are valid.2DC432GLL2.nativeMessagingpermission.Please investigate the peer identity lookup introduced/enabled between
26.901.51231and26.903.61454. The UI should also surfacemissing-code-signing-identityinstead of reporting only a generic Chrome timeout.yuqingzhijie commentedon Sep 23, 2026
yuqingzhijie commentedon Sep 23, 2026
lucasamyers-cmd commentedon Sep 25, 2026
I'm no engineer, but I may be having the same or a related problem.
App Version: 26.917.71314OS
Version: macOS Sonoma 14.1 (Intel/Apple Silicon)
Problem: The local browser-control runtime process (node_repl) crashes immediately upon startup before any browser state can initialize.
Error Log / Blocker:Browser-control runtime crashes at initialization (TIOCSTI sandbox error).
Technical Details: The issue is caused by a hardcoded (deny file-ioctl (ioctl-command TIOCSTI)) rule within the compiled sandbox initialization profile. Because macOS Sonoma strictly requires raw numeric constants for Seatbelt/sandbox-exec compliance rather than symbolic text variables, the OS kernel forcefully terminates the process during initialization with exit code 65. Passing --disable-sandbox flags does not bypass the hardcoded binary constraint. Please replace the TIOCSTI symbolic string with its platform-appropriate numeric constant in the next build.
InnovationLou commentedon Oct 12, 2026
Additional reproduction on Windows 11, with local log inspection on 2026-10-12. The symptoms match this issue, but the underlying cause is not yet established.
Environment
26.1007.2143426.1007.2314.0153.0.8010.531.26.901.11451, IDhehggadaopoacecdllhhajmbjkdcmajg26.1007.2143424.21.0-cua.1; runtime archive version0.0.29/20261005054403-144090e2ddcbbrowser; available backendschrome,iab,mcpappsReproduction
In a desktop chat, select @chrome and ask to list open tabs or read the current tab title.
The first supported API call is:
This repeatedly returns:
Earlier attempts failed with both 30,000 ms and 60,000 ms execution deadlines. Creating a Chrome blank tab and an Edge blank tab also timed out; whether those tabs were actually created could not be verified because state inspection timed out too.
During this diagnostic run, a single
cua.getState()call with a 15,000 ms deadline reproduced the same failure in approximately 17 seconds of tool wall time, before any website navigation or page-content operation.Checks that passed
The bundled read-only diagnostics were run outside the restricted shell sandbox to avoid a misleading sandbox view of HKCU:
check-extension-installed.js --browser chrome --json:installed=true,registered=true,enabled=true,disabled=false,disableReasons=[]in the selected Default profile.check-native-host-manifest.js --browser chrome --json:exists=true,correct=true,nameMatches=true,registryMatchesManifestPath=true,missingExpectedOrigins=[],problem=null.extension-host.exewas running..codex-plugin/plugin.jsonexists and parses as valid JSON with the expected name/version.node_repltool successfully executednodeRepl.write("diagnostic runtime ping");before the CUA failure and another simple write after it. Thus ordinary JS execution is responsive; the failure is specific to the CUA/browser initialization or communication path. This does not establish that the two tools have identical startup/configuration.Sanitized log evidence
All timestamps below are UTC (local timezone UTC+8). Excerpts omit usernames, private paths, profile contents, browsing URLs, and identifiers unrelated to diagnosis.
The fresh reproduction produced this diagnostic in
logs_2.sqlite:The desktop log had reported both MCP services as ready for the affected chat:
Earlier runtime stderr contained a potentially relevant MXC/network-drive warning:
The message means "The specified network name is no longer available." Z: is present as a network-backed filesystem drive. It has not been disconnected or altered, and there has been no controlled comparison without that drive. This warning is a lead, not a confirmed cause of the CUA timeout.
There was also a transient plugin-load/status sequence after an app restart:
The missing-path message means "The system cannot find the path specified." The plugin manifest and runtime files are present now, yet the CUA timeout still reproduces, so the earlier plugin warning alone does not explain the current failure.
Request
Please investigate why CUA/browser state initialization hangs despite passing extension/native-host checks and responsive ordinary JS execution. In particular:
No fix has been verified on this machine. This is a Windows reproduction with diagnostic leads, not a claim that it shares the macOS-specific causes discussed above.
InnovationLou commentedon Oct 12, 2026
Controlled follow-up on 2026-10-12: the timeout was resolved after removing the current mapping of an unavailable network drive; Chrome discovery then recovered after reopening the extension side panel.
A new sandboxed, read-only command stalled before PowerShell began and eventually returned exactly:
The user confirmed that Z: was not in use and explicitly authorized temporary disconnection. The mapping metadata was backed up locally; no share path, credentials, or private browser data are included here.
The only system change was:
This removed Z: from the current logical-drive list while retaining its remembered HKCU reconnect entry. A disconnected SMB mapping record was still listed. No browser profile/cache was deleted, no extension was reinstalled, and no security settings were changed.
Immediately afterward:
MXC_OK, exit 0, in approximately 354 ms.cua.getState()completed in approximately 5 s instead of timing out, listing the in-app browser and MCP Apps.cua.listTabs({browser:"chrome"})returnedBrowser is not available: chromepromptly.This provides a before/after comparison supporting the unavailable mapped volume as the blocker for MXC/CUA startup on this machine. It also distinguishes a remaining extension connection/discovery step from the original kernel timeout. We did not deliberately reconnect the unavailable drive to force the failure again.
The original MXC network-volume signature closely matches #51665 and #50915. The earlier transient plugin warning was not repaired separately during this successful recovery. Please investigate unavailable-volume handling and expose the underlying MXC launch error rather than only an eventual JS deadline/kernel reset.
The current-session drive mapping remains disconnected for troubleshooting; its remembered reconnect information was preserved, so the problem may recur if an unavailable mapping is reintroduced.
stephen-drew commentedon Oct 18, 2026
Additional intermittent Windows occurrence, 18 October 2026. This is a request for a supported diagnostic procedure, not a claim that the previously reported causes apply.
Environment:
At 2026-10-18 22:18:12.647 UTC, the first
cua.getState()call used a caller-supplied 20,000 ms execution deadline. It returnedjs execution timed out; kernel reset, rerun your requestafter 20.1733 seconds.During that call, desktop logs show a burst of 20 IAB
getInforequests at 22:18:14.955-22:18:14.971 UTC. Nineteen returned a missing-session-route error and one completed. The same error also occurs around successful calls, so it does not establish causation. No IAB page was opened or used.Current checks pass:
Installed source shows browser discovery and handshake instrumentation, but the retained logs do not identify the operation which waited during the original timeout. Connection, native policy/header reads, and extension request/response waits cannot be distinguished from the generic timeout. The installed NodeREPL help and CUA README do not document a per-task native trace option.
Please provide a supported way to capture per-request stage timings, outcomes and cancellation for CUA discovery and Chrome tab-inventory calls, ideally without changing global MCP availability or weakening the sandbox. In particular, how can we distinguish a pending native connection,
config.readRequirements()wait, and unansweredgetTabs/getUserTabsrequest? A trace should avoid collecting browser URLs, page contents, credentials and personal data.No permanent cause or repair is claimed. The timeout is not currently reproducible, and repeated healthy canaries cannot establish what happened in the original call.