Chrome plugin Node REPL bootstrap fails from WSL due to Windows path/trust mismatch

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:

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