Browser Use node_repl/js availability diverges by thread in Codex Desktop

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_search is 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__/js is 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.rs lists MCP tools for the session/turn.
• mcp_tool_exposure.rs decides which MCP tools are direct vs deferred.
• tool_search should expose deferred MCP tools when they are in the deferred inventory.
• router.rs can 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:

1. exposed directly, or
2. discoverable through tool_search, or
3. 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:

• #20417
• #20579
• #20678
• #21246