Repository navigation
Browser Use node_repl/js availability diverges by thread in Codex Desktop #21301
Description
Summary
Browser Use can be available in one Codex Desktop thread but unavailable in another thread in the same app/session environment, because the node_repl/js MCP tool is missing from the affected thread's tool inventory. This does not look like a normal lazy-loading/deferred-tool case: tool_search is available, but cannot discover node_repl/js in the affected thread.
Environment
- macOS 26.3.1 arm64
- Codex CLI visible in the app shell:
codex-cli 0.128.0-alpha.1 - Codex Desktop with the in-app browser open
- Browser Use plugin enabled in local config
- Same machine, same workspace/cwd, same day
Observed behavior
In one thread:
- Browser Use skill/plugin instructions are present.
tool_searchis available.- Searching for
node_repl js,mcp__node_repl__js,js, or similar terms returns no Node REPL MCP tool. - Therefore Browser Use cannot call
mcp__node_repl__/js. - Trying to use the Browser Use runtime from a plain shell Node process is not a substitute, because it fails without Codex session metadata for the IAB backend.
In another thread in the same Codex Desktop app:
mcp__node_repl__/jsis available and was called successfully multiple times for Browser Use actions such as opening the dashboard, taking snapshots, screenshots, and interacting with menus.
I compared the two local session records and the persisted dynamic_tools set was the same. The difference was not per-thread dynamic tools. The affected thread simply did not have node_repl/js in its MCP/tool-search inventory, while the working thread did.
Why this looks like a tool inventory / MCP exposure issue
I checked the current openai/codex source and the expected flow appears to be:
turn.rslists MCP tools for the session/turn.mcp_tool_exposure.rsdecides which MCP tools are direct vs deferred.tool_searchshould expose deferred MCP tools when they are in the deferred inventory.router.rscan then resolve MCP calls when the tool info exists.
In the affected thread, tool_search cannot find node_repl/js at all, so this looks like the tool is missing from that thread's MCP inventory rather than merely being hidden/deferred.
Expected behavior
If Browser Use is enabled and its skill is available in a thread, the required execution tool (node_repl/js / mcp__node_repl__/js) should be either:
- exposed directly, or
- discoverable through
tool_search, or - accompanied by a clear error explaining why the MCP server/tool failed to load for that thread.
A new/resumed thread should not silently lose the Browser Use execution MCP tool while another thread in the same app has it.
Related issues
Possibly related, but this report is specifically about per-thread divergence on the same macOS desktop environment:
- Windows Codex Desktop WSL: Browser Use IAB skill unavailable because node_repl/js tool is not injected #20417
- Browser Use broken after today update: no node_repl/js or no Codex IAB backend discovered #20579
- fix(browser): Browser Use cannot connect to IAB from Node REPL on macOS #20678
- In-app browser inspection is blocked when node_repl requires Node >= 22.22.0 but desktop environment resolves Node 18 #21246
Activity
github-actions commentedon May 6, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
hyunn515 commentedon May 6, 2026
I found a local workaround for the affected desktop environment: explicitly register the bundled Node REPL MCP server in
~/.codex/config.toml.The executable exists in the Codex.app bundle and responds to a direct MCP initialize +
tools/listprobe withjsandjs_reset. After adding it,codex mcp listshowsnode_replas an enabled stdio server.This does not change the underlying bug report: Browser Use is enabled, but the required
node_repl/jsexecution tool can be absent from one thread's tool inventory while present in another. The explicit config entry just makes the server available through the normal MCP configuration path for future turns/threads.