Summary
On Windows with Codex running in WSL, the Chrome plugin can show enabled/connected on both the Codex and Chrome sides, but new agent turns cannot actually complete the Chrome skill bootstrap. The failure happens before browser automation is usable.
Observed failures
Depending on the local workaround state, fresh turns hit one of these errors:
Node runtime not found; install Node or set NODE_REPL_NODE_PATH
Module not found: /mnt/c/.../.codex/plugins/cache/openai-bundled/chrome/latest/scripts/browser-client.mjs
privileged native pipe bridge is not available; browser-client is not trusted
Earlier in the same install path there was also a plugin install issue where installManifest.mjs rewrote chrome/0.1.7 to chrome/latest, but chrome/latest did not exist until it was manually copied from the versioned plugin directory.
Environment shape
- Windows host with Chrome and Codex Chrome Extension installed.
- Codex desktop / agent runtime running from WSL with workspace paths like
/mnt/c/....
- Chrome native host manifest and registry entry exist on Windows.
extension-host.exe is running.- Chrome plugin is enabled in Codex config.
Root cause from debugging
There appear to be three WSL boundary mismatches:
- The
node_repl MCP command may be configured as a Windows .exe path that cannot correctly launch the bundled Windows Node runtime from the WSL/sandbox context, so node_repl is missing or reports no Node runtime.
- When
node_repl is made to run using the Windows bundled Node, the Chrome skill still tells agents to import browser-client.mjs using the WSL plugin path (/mnt/c/...). That import fails because the Node process is Windows-backed and needs a Windows path/file URL such as file:///C:/.../browser-client.mjs.
- After using a Windows file URL,
node_repl still rejects the Chrome browser-client unless the exact bundled browser-client.mjs hash is trusted via NODE_REPL_TRUSTED_BROWSER_CLIENT_SHA256S. In this WSL/custom-wrapper path, that trust information does not appear to be propagated automatically.
Local workaround that made smoke tests pass
A WSL wrapper for node_repl was configured to launch through Windows cmd.exe, set the bundled Windows Node path, and trust only the exact SHA-256 of the installed Chrome browser-client.mjs:
#!/usr/bin/env bash
exec /mnt/c/Windows/System32/cmd.exe /c "set NODE_REPL_NODE_PATH=C:\\Users\\<user>\\.cache\\codex-runtimes\\codex-primary-runtime\\dependencies\\node\\bin\\node.exe && set NODE_REPL_TRUSTED_BROWSER_CLIENT_SHA256S=<sha256-of-browser-client.mjs> && C:\\Users\\<user>\\AppData\\Local\\OpenAI\\Codex\\bin\\node_repl.exe"
The local Chrome skill bootstrap examples also had to use the Windows file URL for browser-client.mjs rather than the /mnt/c/... path.
After those two changes, a fresh codex exec smoke test using @chrome and calling only browser.user.openTabs() succeeded and returned the live Chrome tab list.
Expected fix
For Windows+WSL sessions, Codex/Chrome plugin setup should automatically:
- expose the
node_repl js tool in new turns,
- launch
node_repl with a Node executable that works across the WSL/Windows boundary,
- provide an importable browser-client path compatible with the actual Node runtime path semantics,
- propagate the trusted Chrome browser-client hash/path metadata to
node_repl, and
- ensure
chrome/latest exists or avoid rewriting to it when only a versioned plugin directory exists.
The user-facing symptom is that the Chrome plugin looks healthy/connected, but @chrome cannot actually control Chrome until these path/trust issues are manually worked around.
Summary
On Windows with Codex running in WSL, the Chrome plugin can show enabled/connected on both the Codex and Chrome sides, but new agent turns cannot actually complete the Chrome skill bootstrap. The failure happens before browser automation is usable.
Observed failures
Depending on the local workaround state, fresh turns hit one of these errors:
Earlier in the same install path there was also a plugin install issue where
installManifest.mjsrewrotechrome/0.1.7tochrome/latest, butchrome/latestdid not exist until it was manually copied from the versioned plugin directory.Environment shape
/mnt/c/....extension-host.exeis running.Root cause from debugging
There appear to be three WSL boundary mismatches:
node_replMCP command may be configured as a Windows.exepath that cannot correctly launch the bundled Windows Node runtime from the WSL/sandbox context, sonode_replis missing or reports no Node runtime.node_replis made to run using the Windows bundled Node, the Chrome skill still tells agents to importbrowser-client.mjsusing the WSL plugin path (/mnt/c/...). That import fails because the Node process is Windows-backed and needs a Windows path/file URL such asfile:///C:/.../browser-client.mjs.node_replstill rejects the Chrome browser-client unless the exact bundledbrowser-client.mjshash is trusted viaNODE_REPL_TRUSTED_BROWSER_CLIENT_SHA256S. In this WSL/custom-wrapper path, that trust information does not appear to be propagated automatically.Local workaround that made smoke tests pass
A WSL wrapper for
node_replwas configured to launch through Windowscmd.exe, set the bundled Windows Node path, and trust only the exact SHA-256 of the installed Chromebrowser-client.mjs:The local Chrome skill bootstrap examples also had to use the Windows file URL for
browser-client.mjsrather than the/mnt/c/...path.After those two changes, a fresh
codex execsmoke test using@chromeand calling onlybrowser.user.openTabs()succeeded and returned the live Chrome tab list.Expected fix
For Windows+WSL sessions, Codex/Chrome plugin setup should automatically:
node_repljstool in new turns,node_replwith a Node executable that works across the WSL/Windows boundary,node_repl, andchrome/latestexists or avoid rewriting to it when only a versioned plugin directory exists.The user-facing symptom is that the Chrome plugin looks healthy/connected, but
@chromecannot actually control Chrome until these path/trust issues are manually worked around.