Skip to content

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

Open
Open
Chrome plugin Node REPL bootstrap fails from WSL due to Windows path/trust mismatch#21971
Labels
appIssues related to the Codex desktop appbrowserbugSomething isn't workingskillsIssues related to skillswindows-osIssues related to Codex on Windows systems

Description

@MisterRound
MisterRound
opened on May 9, 2026

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.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    skillsIssues related to skills
    browser
    on May 9, 2026

  2. github-actions commented on May 9, 2026

    @github-actions
    github-actionsBot
    on May 9, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. MisterRound
    changed the title [-]Chrome plugin Node REPL bootstrap fails from WSL due Windows path/trust mismatch[/-] [+]Chrome plugin Node REPL bootstrap fails from WSL due to Windows path/trust mismatch[/+] on May 9, 2026

  4. bbbiggest commented on Jun 10, 2026

    @bbbiggest
    bbbiggest
    on Jun 10, 2026

    I hit a very similar failure on Windows + WSL with the bundled Chrome plugin.

    Setup:

    • Windows host, WSL-backed Codex Desktop session/workspace
    • Chrome plugin cache dir: openai-bundled/chrome/26.608.12217
    • Codex Chrome Extension installed and enabled
    • Native host registry entry present
    • After a fresh Chrome restart, agent.browsers.get("extension") failed with Browser is not available: extension

    The native host manifest at %LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json was being written with:

    "path": "\\mnt\\c\\Users\\<user>\\.codex\\plugins\\cache\\openai-bundled\\chrome\\latest\\extension-host\\windows\\x64\\extension-host.exe"

    But there was no chrome\latest directory. The actual host binary was at:

    C:\Users\<user>\.codex\plugins\cache\openai-bundled\chrome\26.608.12217\extension-host\windows\x64\extension-host.exe

    Rewriting the manifest to that real Windows path restored Chrome plugin bootstrap after a full Chrome restart; browser.user.openTabs() returned the live tab list again. The workaround only stuck once the manifest stopped being overwritten back to the /mnt/c-style path.

    This seems related to #24268, but in this case the bad WSL/Windows path ends up directly in the Chrome Native Messaging Host manifest.

    My guess for the durable fix:

    • when writing a Windows native host manifest, convert /mnt/<drive>/... to <drive>:\... or use the Windows-side cache path directly;
    • avoid rewriting the versioned plugin dir to chrome/latest unless that alias exists, or create/update the alias during install/reconcile.

  5. MisterRound commented on Jun 10, 2026

    @MisterRound
    MisterRound
    on Jun 10, 2026
    Author

    Updated Chrome/node_repl WSL findings from the same Windows Desktop + WSL environment.

    The current working local shape is:

    • top-level node_repl MCP server is routed through a WSL wrapper;
    • wrapper launches Windows node_repl.exe --disable-sandbox from an isolated Windows runtime home:
    %USERPROFILE%\.codex\chrome-runtime-home
    • Chrome native host manifests use native Windows paths to a real plugin cache directory;
    • imports use Windows file URLs from the Windows-backed Node runtime, e.g.
    file:///C:/Users/<user>/.codex/plugins/cache/openai-bundled/chrome/<version>/scripts/browser-client.mjs
    • the real smoke API is:
    browser.user.openTabs()

    or, in the current runtime shape, the extension backend under the populated agent object.

    Important distinction for debugging:

    • browser.tabs.list() can correctly return an empty array because it lists automation-owned tabs.
    • browser.user.openTabs() is the user-tab smoke that proves the extension path can see live user tabs.
    • browser.tabs.query is not part of the wrapper API I tested.

    The Chrome path can now work while still not proving the underlying WSL shell/arg0 bug is fixed. The acceptance gate after a Chrome smoke should include:

    • nodeRepl.cwd is the isolated Windows runtime home;
    • shared %USERPROFILE%\.codex\tmp\arg0 remains WSL/Linux-only;
    • Windows .bat helpers appear only under the isolated runtime home;
    • no bare/shared-home node_repl.exe -> codex.exe app-server --listen stdio:// sidecar is spawned.

    This matters because earlier successful Chrome smokes still triggered product-generated bare sidecars that polluted shared arg0. The durable product fix is not only path normalization for Chrome native host files; it also needs product-generated browser/CUA node_repl sidecars in Desktop WSL mode to use an isolated Windows runtime home by default.

  6. yui-stingray commented on Jun 17, 2026

    @yui-stingray
    yui-stingray
    on Jun 17, 2026

    I’m seeing a related Windows + WSL Chrome plugin failure with a slightly different local signal.

    Environment:

    • Windows host with Codex Desktop using WSL agent runtime
    • WSL distro: Ubuntu 22.04.5 LTS
    • Codex CLI in WSL: 0.140.0
    • Chrome plugin cache in WSL: chrome@openai-bundled 26.611.61049
    • Google Chrome in WSL: 149.0.7827.114
    • Node in WSL: v22.20.0
    • Codex Chrome Extension in the WSL Chrome profile: 1.1.5_0

    Observed behavior:

    1. I removed and re-added the Chrome plugin from the Codex plugin UI.
    2. The UI showed an error indicating the add/install failed, but the plugin still appeared as installed/added afterward.
    3. Starting WSL Chrome works, and the extension is installed/enabled/registered in the WSL Chrome Default profile.
    4. However, Codex cannot acquire the Chrome extension backend:

    Browser is not available: extension

    Local diagnostics:

    • scripts/check-extension-installed.js --json reports the extension installed/enabled/registered in the WSL Chrome profile.
    • scripts/check-native-host-manifest.js --json cannot validate this setup because it exits with:

    Unsupported platform for native host manifest check: linux. This script supports macOS and Windows.

    Native Messaging manifest issue:
    The WSL Chrome Native Messaging manifest exists at:

    <WSL_HOME>/.config/google-chrome/NativeMessagingHosts/com.openai.codexextension.json

    But it points to a stale Windows-side plugin path:

    <WINDOWS_HOME>/.codex/plugins/cache/openai-bundled/chrome/0.1.7/extension-host/windows/x64/extension-host.exe

    That target no longer exists.

    The current WSL plugin cache is:

    <WSL_HOME>/.codex/plugins/cache/openai-bundled/chrome/26.611.61049

    and the only extension-host binary found under the current cache is:

    <WSL_HOME>/.codex/plugins/cache/openai-bundled/chrome/26.611.61049/extension-host/windows/x64/extension-host.exe

    file identifies it as:

    PE32+ executable (console) x86-64, for MS Windows

    Expected behavior:

    • Reinstalling/re-adding the Chrome plugin should either:
      • correctly install/update the native messaging manifest for the active WSL Chrome profile, or
      • clearly report that WSL/Linux Chrome is not supported for this plugin path.
    • If the plugin add fails, the UI should not leave the plugin in an apparently installed/healthy state.
    • agent.browsers.get("extension") should either work or return an actionable reason.

    Actual behavior:

    • Plugin UI appears installed after an add failure.
    • WSL Chrome extension is installed/enabled.
    • Native Messaging manifest remains stale and points to a missing old Windows path.
    • Chrome backend remains unavailable with Browser is not available: extension.

    I avoided manual manifest edits because this looks like a plugin install/native-host registration boundary issue rather than a user config issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbrowserbugSomething isn't workingskillsIssues related to skillswindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions