Windows Codex App: Browser Use unavailable because Node REPL tool is not exposed

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

• #18328
• #19271

Powered by Codex Action

Hi, do you have a custom provider set up in the config? Aside from js_repl, are the other mcp tools available?

I can reproduce a very similar failure on Windows + WSL.

Environment:

Codex Desktop Windows: 26.422.2437.0
codex-cli: 0.124.0-alpha.2
WSL: Linux 6.6.87.2-microsoft-standard-WSL2 x86_64
Browser Use plugin: openai-bundled/browser-use/0.1.0-alpha1

Answering the custom-provider question: I do not appear to have an active custom provider selected. The top-level model_provider entries in config.toml are commented out. There is a model_providers.openai-http block present, but it is not selected by an active top-level model_provider.

Other tools/connectors are available in the session, including normal shell tools, the generic functions.js_repl, GitHub connector tools, and the OpenAI docs MCP. The missing part appears to be specifically the Browser Use / Node REPL bridge expected by the Browser Use skill.

Local config includes:

[features]
js_repl = true
plugins = true
apps = true

[plugins."browser-use@openai-bundled"]
enabled = true

The Browser Use client file exists:

~/.codex/plugins/cache/openai-bundled/browser-use/0.1.0-alpha1/scripts/browser-client.mjs

But tool discovery cannot find the expected Browser Use Node REPL execution tools:

mcp__node_repl__js
node_repl js
js
node_repl js JavaScript execution

The exposed generic JS REPL is not equivalent to the expected nodeRepl environment. In functions.js_repl, this is the observed shape:

{
  hasNodeRepl: false,
  codexKeys: ["cwd", "homeDir", "tmpDir", "tool", "emitImage"]
}

Also, the Browser Use socket path exists but contains no backend socket:

/tmp/codex-browser-use:
(empty directory)

When attempting to initialise the Browser Use client through the available generic JS REPL, it cannot attach to the IAB backend because no Codex browser session metadata is present:

Failed to connect to browser-use backend "iab". No current Codex session metadata was available, so IAB ownership could not be checked.

So this looks like the same class of issue: js_repl = true is enabled and the Browser Use plugin is installed, but the session does not expose the Node REPL/browser bridge that browser-client.mjs expects.

Answering the custom-provider question: I do not have a custom provider selected. My config uses:

model = "gpt-5.5"

There is no active top-level model_provider set.

Other MCP/tools are available in the session, including normal shell tools and configured MCP servers such as Supabase and Cloudflare. The missing part appears to be specifically the Node REPL / Browser Use bridge expected by the Browser Use skill.

I also tested the WindowsApps bundled Node runtime directly and it fails with Access is denied:

C:\Program Files\WindowsApps\OpenAI.Codex_26.422.2437.0_x64__2p2nqsd0c76g0\app\resources\node.exe
Program 'node.exe' failed to run: Access is denied

So this looks closely related to #19271. The visible symptom in my session is that mcp__node_repl__js is not exposed at all, but the likely underlying cause may be the same WindowsApps bundled node.exe execution failure.

I can reproduce a very similar failure on a newer Windows Desktop / WSL setup. The notable difference from earlier reports is that js_repl now appears as removed false, while browser_use and in_app_browser are enabled.

What issue are you seeing?

Browser Use is installed and enabled, but the session does not expose the Node REPL / JavaScript execution tool required by the Browser Use skill, so Browser Use cannot bootstrap against the in-app browser.

Environment:

Codex Desktop Windows About dialog: 26.422.62136
Windows package metadata from Get-AppxPackage: 26.422.8496.0
codex-cli: 0.126.0-alpha.8
WSL: Linux 6.6.87.2-microsoft-standard-WSL2 x86_64
Browser Use plugin: openai-bundled/browser-use/0.1.0-alpha1

Feature state:

apps                                stable             true
browser_use                         stable             true
computer_use                        stable             true
in_app_browser                      stable             true
js_repl                             removed            false
js_repl_tools_only                  removed            false
plugins                             stable             true

The Browser Use plugin and client file exist:

~/.codex/plugins/cache/openai-bundled/browser-use/0.1.0-alpha1/scripts/browser-client.mjs

The Browser Use skill still requires the Node REPL js execution tool in order to run:

await setupAtlasRuntime({ globals: globalThis, backend: "iab" });

But after fully restarting Codex Desktop and opening a fresh thread, tool discovery still does not expose any of:

node_repl js
mcp__node_repl__js
js
js_reset

What steps can reproduce the bug?

1. Use Codex Desktop on Windows with a WSL workspace.
2. Ensure Browser Use is installed and enabled.
3. Confirm feature state with:

codex features list | rg 'apps|plugins|browser_use|in_app_browser|computer_use|js_repl'

1. Fully quit and restart Codex Desktop.
2. Open a fresh thread and ask Codex to use @browser-use on an open in-app browser tab.
3. The Browser Use skill reads its instructions, but cannot proceed because the required Node REPL JavaScript execution tool is not present in the session.

I also tried the Windows helper-binary workaround mentioned in related reports by copying these files from the packaged local cache into %LOCALAPPDATA%\OpenAI\Codex\bin:

codex.exe
node.exe
node_repl.exe
codex-command-runner.exe
codex-windows-sandbox-setup.exe

The copied binaries are present, and both codex.exe and the WSL launcher report:

codex-cli 0.126.0-alpha.8

Running node_repl.exe directly starts far enough to attempt stdio MCP initialization, then exits because it was not launched by Codex with an initialize handshake:

Error: failed to start stdio MCP server
Caused by:
    connection closed: initialize request

So the helper binary exists, but the Codex session still does not provision the Node REPL / Browser Use bridge tool.

What is the expected behavior?

When browser_use and in_app_browser are enabled and the Browser Use plugin is installed, Codex sessions should expose whatever execution tool the Browser Use skill currently requires, or the skill should use the replacement Browser Use pathway if js_repl / Node REPL has been removed.

At minimum, the session should report a clear remediation path when Browser Use is enabled but its required execution bridge is unavailable.

Additional information

This looks like either:

1. the Browser Use skill is stale and still points to a removed js_repl / Node REPL tool path, or
2. the app should expose a replacement Browser Use execution tool, but that tool is not being provisioned into Windows + WSL sessions.

The current failure mode is confusing because the feature flags imply Browser Use is enabled, while the documented bootstrap path in the installed skill requires a tool that is not available in this build.

Codex Desktop Windows 26.429.3425.0

Browser Use / in-app browser cannot open google.com.

Initial failure:
failed to execute Node: Access is denied. (os error 5)

Confirmed:
C:\Program Files\WindowsApps\OpenAI.Codex_26.429.3425.0_x64__2p2nqsd0c76g0\app\resources\node.exe
→ Access is denied

C:\Program Files\WindowsApps\OpenAI.Codex_26.429.3425.0_x64__2p2nqsd0c76g0\app\resources\rg.exe
→ Access is denied

Confirmed working:
C:\Users\mmggr\.cache\codex-runtimes\codex-primary-runtime\dependencies\node\bin\node.exe
→ v24.14.0

Workaround tried:
Copied the working node.exe into recent:
C:\Users\mmggr\.codex\tmp\...\codex-arg*

Result:
node_repl minimal calls started working and Browser Use could detect an about:blank tab.

New failure:
Trying to open https://www.google.com causes node_repl/kernel to close and Codex falls back to:
windows sandbox failed: runner error: CreateProcessAsUserW failed: 5

Also tried:
[windows]
sandbox = "unelevated"

Result:
Does not fix Browser Use. node_repl / Browser Use still fail.

Tried enabling runCodexInWindowsSubsystemForLinux manually in:
C:\Users\mmggr\.codex\.codex-global-state.json

Result:
Codex hangs indefinitely when running pwd, so WSL agent mode is not usable from this build/UI.

Conclusion:
This appears to combine the WindowsApps packaged helper execution failure with the Windows sandbox CreateProcessAsUserW failed: 5 issue. Browser Use remains unusable on this Windows Desktop build.

Additional data point from Windows Desktop 26.506.3741.0 / bundled CLI 0.130.0-alpha.5.

Feature state from the bundled CLI:

browser_use                             stable   true
browser_use_external                    stable   true
in_app_browser                          stable   true
js_repl                                 removed  false
js_repl_tools_only                      removed  false
plugins                                 stable   true
tool_search                             stable   true

The bundled Browser Use plugin is enabled in config.toml:

[plugins.browser-use@openai-bundled]
enabled = true

In the active Desktop session, a tool discovery query for node_repl js mcp__node_repl__js browser-use did not expose mcp__node_repl__js, node_repl js, js, or js_reset as callable tools.

At the same time, the app-server has many live node_repl.exe children:

codex.exe app-server PID 8536
node_repl.exe children: 34
combined working set: ~639 MB

So this is not simply “the node_repl binary is missing”. The process host exists and is being spawned, but the Browser Use-required callable tool is not reliably present in the model/tool environment.

This also seems distinct from the process accumulation issue tracked in #20883/#21984: there are too many node_repl.exe host processes, yet the current agent can still report that the Node REPL browser tool is unavailable. Those two symptoms probably share the same Node REPL / Browser Use / MCP integration area, but one is tool injection/discovery and the other is process lifecycle cleanup.

Additional Windows data point connecting Node REPL tool injection failure with fallback browser process growth.

After mcp__node_repl__js / node_repl js was not exposed reliably, agents used a Chrome DevTools / controlled-profile fallback. On this machine that fallback path grew substantially:

Codex Desktop: 26.506.3741.0
controlled_chrome_profile / remote-debugging-port=9444:
  chrome.exe processes: 74
  working set: ~10.4 GB
  oldest process: 2026-05-12 02:19:30
  newest process: 2026-05-12 13:27:48

playwright_chromiumdev_profile temp profile:
  chrome.exe processes: 20
  working set: ~1.6 GB

Important distinction: the machine also had a separate node_repl.exe lifecycle leak, now mitigated locally by a conservative cleanup task. But these Chrome processes are separate and became the dominant memory footprint. So the Node REPL tool-injection problem can push agents toward fallback browser control, and that fallback path appears to have its own lifecycle/cleanup risk.

Related routing/fallback issue: #21868. Related browser process lifecycle issue: #17832.

Additional current data point after the Browser Use plugin was replaced by the newer Chrome plugin path.

Environment:

Codex Desktop Windows package: 26.519.3891.0
Bundled WSL app-server CLI: 0.133.0-alpha.1
Chrome plugin: chrome@openai-bundled 26.519.31651
Platform: Windows + WSL2 workspace
Desktop mode: runCodexInWindowsSubsystemForLinux = true

Current plugin/config state:

chrome@openai-bundled (installed, enabled)
[plugins."chrome@openai-bundled"] enabled = true

I removed the stale old config block for browser-use@openai-bundled; it no longer appears in config.toml. The old browser-use plugin also no longer appears in the current openai-bundled marketplace on this install.

The Chrome plugin cache now appears structurally valid:

~/.codex/plugins/cache/openai-bundled/chrome/26.519.31651/.codex-plugin/plugin.json
~/.codex/plugins/cache/openai-bundled/chrome/26.519.31651/scripts/browser-client.mjs
~/.codex/plugins/cache/openai-bundled/chrome/26.519.31651/app-server-runtime/codex
~/.codex/plugins/cache/openai-bundled/chrome/26.519.31651/app-server-runtime/node
~/.codex/plugins/cache/openai-bundled/chrome/26.519.31651/app-server-runtime/node_repl

After a clean remove/add of the Chrome plugin and a full Codex Desktop restart, the previous loader error is gone. I no longer see fresh missing or invalid plugin.json warnings for chrome@openai-bundled.

However, the actual browser-control tool surface is still not exposed to the model. When asking Codex with the explicit plugin mention:

[@Chrome](plugin://chrome@openai-bundled) list open tabs

Tool discovery still does not return any Chrome / Browser Use / Node REPL execution tool. It returns unrelated tools such as DataForSEO, Figma, and Supabase. No callable tool such as these appears:

mcp__node_repl__js
node_repl js
js
js_reset
browser.user.openTabs

Feature state is also notable:

browser_use                             stable             true
browser_use_external                    stable             true
computer_use                            stable             true
in_app_browser                          stable             true
plugins                                 stable             true
plugin_hooks                            stable             true
js_repl                                 removed            false
js_repl_tools_only                      removed            false

So this no longer looks like a broken plugin cache or native-host install problem. The Chrome plugin is installed and enabled, the cache contains the expected runtime files, and the app-server starts normally from the bundled WSL binary, but the runtime/tool interface expected by the Chrome skill is not injected into the model session.

In short: on the current Chrome plugin path, the failure mode appears to have moved from “Browser Use plugin cannot bootstrap because Node REPL is missing” to “Chrome plugin route/skill is present, but the browser runtime / Node REPL-backed callable tool surface is still not exposed.”

Follow-up: I found a local workaround and it also narrows the failure mode.

Switching Codex Desktop from the WSL app-server path to native Windows execution fixed the Chrome plugin tool exposure problem on my machine. After moving Codex to Windows native mode, @Chrome browser control works again.

So the issue appears specific to the Windows + WSL app-server path rather than the Chrome plugin installation itself:

Broken: Codex Desktop running app-server in WSL via runCodexInWindowsSubsystemForLinux = true
Working: Codex Desktop running natively on Windows

This is a viable workaround for me, but I do not think it fully resolves the underlying bug because the WSL app-server mode still fails to expose the Chrome/browser-control runtime tools even when the Chrome plugin is installed and enabled.

I’m seeing the same class of Browser/Chrome tool exposure failure on a newer Windows Desktop build, with an additional data point about js_repl being rewritten after restart.

Environment

Codex Desktop Windows package: 26.609.9530.0
Bundled/user CLI: codex-cli 0.140.0-alpha.2
Platform: Windows native mode
runCodexInWindowsSubsystemForLinux = false
Browser plugin: browser@openai-bundled enabled
Chrome plugin: chrome@openai-bundled enabled

Current config after a normal Codex restart

[plugins."browser@openai-bundled"]
enabled = true

[plugins."chrome@openai-bundled"]
enabled = true

[features]
js_repl = false

[desktop]
runCodexInWindowsSubsystemForLinux = false

[mcp_servers.node_repl]
command = 'C:\Users\white\AppData\Local\OpenAI\Codex\runtimes\cua_node\789504f803e82e2b\bin\node_repl.exe'
startup_timeout_sec = 120

Feature state

browser_use stable true
browser_use_external stable true
computer_use stable true
in_app_browser stable true
js_repl removed false
js_repl_tools_only removed false
plugins stable true
tool_search removed false

What I tried

The Browser and Chrome plugin files exist locally, including:

C:\Users\white\.codex\plugins\cache\openai-bundled\browser\26.609.71450\scripts\browser-client.mjs
C:\Users\white\.codex\plugins\cache\openai-bundled\chrome\26.609.71450\scripts\browser-client.mjs

However, tool discovery still does not expose any of the Browser/Chrome control or Node REPL execution tools expected by the installed Browser/Chrome skills:

mcp__node_repl__js
node_repl js
js
js_reset
browser.user.openTabs

I also manually changed:

[features]
js_repl = true

and made config.toml read-only before launching Codex. This can preserve the file-level js_repl = true value, but it does not make the Browser/Chrome control tools appear. I tried that more than ten times with the same result.

When config.toml is not read-only and Codex is restarted normally, Codex rewrites the setting back to:

js_repl = false

So the important distinction is:

• config.toml can be forced to say js_repl = true
• but the runtime feature registry still reports js_repl removed false
• and the callable tool surface still does not include mcp__node_repl__js / node_repl js

I also noticed the original issue mentions enabling the feature from WSL:

/mnt/c/Users/kutay/.codex/bin/wsl/codex features enable js_repl

I have a similar WSL codex binary locally:

C:\Users\white\.codex\bin\wsl\48731301ce01af57\codex

but this machine currently has no WSL distribution installed, so wsl.exe cannot run it. wsl.exe --list --verbose fails because there is no installed distro.

Possible related WindowsApps execution issue

There is also a possibly related WindowsApps execution issue. The running app-server process is:

C:\Program Files\WindowsApps\OpenAI.Codex_26.609.9530.0_x64__2p2nqsd0c76g0\app\resources\codex.exe

Trying to execute these directly returns Access denied:

C:\Program Files\WindowsApps\OpenAI.Codex_26.609.9530.0_x64__2p2nqsd0c76g0\app\resources\codex.exe
-> Access is denied

C:\Program Files\WindowsApps\OpenAI.Codex_26.609.9530.0_x64__2p2nqsd0c76g0\app\resources\rg.exe
-> Access is denied

But the per-user CLI works:

C:\Users\white\AppData\Local\OpenAI\Codex\bin\f1c7ee7a13db5fed\codex.exe
-> codex-cli 0.140.0-alpha.2

Summary

Even in native Windows mode with runCodexInWindowsSubsystemForLinux = false, Browser/Chrome plugins installed, and mcp_servers.node_repl configured, the active session does not expose the browser-control execution tool.

Forcing js_repl = true in config does not help because the runtime reports js_repl removed false, the Browser/Chrome tools are still not injected, and Codex rewrites the setting back to false after restart when the config file is writable.

This looks like the current Desktop/runtime feature registry has removed or disabled js_repl, while the installed Browser/Chrome skills still require the Node REPL-backed execution path.

This seems related to #19365, #26133, #26732, and possibly the WindowsApps execution issues in #19271 / #21496 / #27313.

Update: see the follow-up below. After this same thread was opened successfully in Codex Desktop, the Browser runtime became visible. Treat the empty backend list below as a pre-Desktop-handoff observation, not as evidence of a standalone Browser plugin/tool-injection failure.

I have a related observation from Windows 10 with the newer bundled Browser plugin present.

Environment:

OS: Windows 10 Pro
Codex CLI: codex-cli 0.140.0, standalone Windows install
Codex Desktop: OpenAI.Codex_26.609.4994.0_x64__2p2nqsd0c76g0
Browser plugin cache: openai-bundled/browser/26.609.41114

The Browser skill was visible to the CLI session, and node_repl itself was available. However, after loading the browser client from the bundled Browser plugin, the in-app browser backend list was empty:

const { setupBrowserRuntime } = await import("C:/Users/<user>/.codex/plugins/cache/openai-bundled/browser/26.609.41114/scripts/browser-client.mjs");
await setupBrowserRuntime({ globals: globalThis });
const browsers = await agent.browsers.list();

Result:

{ "ok": true, "browsers": [] }

At the same time, stale native-host config still referenced older Desktop/plugin/runtime paths, including a codexCliPath pointing to codex-cli 0.135.0-alpha.1, while the active CLI was 0.140.0 and the newer Desktop runtime was 0.140.0-alpha.2.

So this may be another symptom of the stale Desktop/browser runtime sync described in #26011 / #26792 rather than a separate Browser skill issue. I have not isolated a separate root cause yet. I am leaving this as an additional data point rather than proposing a code change for Browser Use at this stage.

Follow-up/correction from the same Windows 10 machine: after validating the /app Desktop handoff fix from #28667, the Browser runtime became visible to the CLI session.

Earlier, before the successful Desktop handoff, this returned an empty browser list:

const { setupBrowserRuntime } = await import("C:/Users/<user>/.codex/plugins/cache/openai-bundled/browser/26.609.41114/scripts/browser-client.mjs");
await setupBrowserRuntime({ globals: globalThis });
await agent.browsers.list();
// []

After opening the same thread in Codex Desktop via the protocol-handler /app path, the same check returned an in-app browser backend:

{
  "ok": true,
  "browsers": [
    {
      "name": "Codex In-app Browser",
      "type": "iab",
      "metadata": {
        "codexAppBuildFlavor": "prod",
        "codexIabTabMode": "singleTab"
      }
    }
  ]
}

So on this repro, the earlier empty Browser backend list may have been caused by the session not being successfully handed off/opened in Desktop yet, rather than by a standalone Browser-plugin tool-injection failure.

The stale native-host config issue still remains separately: both chrome-native-hosts.json files still reference the old codex-cli 0.135.0-alpha.1 path even after Desktop launched successfully. I am keeping that evidence under #26011 rather than treating it as proof of this Browser issue.

I can reproduce this on a current native Windows Desktop build, with a stronger isolation of the failing layer.

Environment

Codex Desktop package: OpenAI.Codex_26.707.9981.0_x64
Codex CLI: 0.144.2
Chrome plugin: 26.707.72221
Computer Use plugin: 26.707.72221
OS: Windows 11 Pro 10.0.26200 x64
Task ID: 019f6658-3faf-75b0-8c49-752b43cbdda2

Confirmed healthy

• Chrome extension is installed and enabled in the selected Chrome profile.
• Native messaging host manifest exists, matches the expected host and extension origin, and the registry points to the same manifest.
• Desktop logs report both:
• browser-use native pipe listening
• computer-use native pipe startup ready
• Desktop selects valid per-user runtime paths:
• Node v24.14.0
• node_repl.exe
• per-user codex.exe
• codex mcp list shows node_repl enabled.
• A direct MCP initialize + tools/list handshake against the configured node_repl.exe succeeds and returns:
• js
• js_add_node_module_dir
• js_reset
• A direct js diagnostic with the task's x-codex-turn-metadata successfully initializes the bundled browser client. agent.browsers.list() returns both:
• the live Chrome extension backend
• the Codex in-app browser backend

This rules out extension installation, native-host registration, native-pipe startup, Node execution, Node REPL startup, MCP handshake, and browser-backend discovery.

Failing layer

The Desktop task's callable/deferred tool surface does not expose any of:

mcp__node_repl__js
node_repl js
js
js_reset

It also does not expose a tool-discovery entry that can retrieve the deferred Node REPL tools. Other connector/plugin tools are available normally.

Feature state:

browser_use                          stable   true
browser_use_external                 stable   true
computer_use                         stable   true
in_app_browser                       stable   true
js_repl                              removed  false
js_repl_tools_only                   removed  false
tool_search                          removed  false

The Chrome plugin has been removed/re-added and the app restarted repeatedly (seven complete reinstall attempts) with no change.

Conclusion

In this reproduction, the failure is specifically after successful MCP/browser discovery and before per-task tool registration/indexing. The backend is live and usable, but Desktop/App Server omits the required Node REPL tools from the task tool store. This also looks related to #19425 and #21451, but unlike #21451 the discovery surface itself is unavailable in this task.