Skip to content

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

Open

Description

@hyunn515

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:

Activity

  1. added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    mcpIssues related to the use of model context protocol (MCP) servers
    sessionIssues involving session (thread) management, resuming, forking, naming, archiving
    on May 6, 2026
  2. hyunn515 commented on May 6, 2026

    @hyunn515
    Author

    I found a local workaround for the affected desktop environment: explicitly register the bundled Node REPL MCP server in ~/.codex/config.toml.

    [mcp_servers.node_repl]
    command = "/Applications/Codex.app/Contents/Resources/node_repl"

    The executable exists in the Codex.app bundle and responds to a direct MCP initialize + tools/list probe with js and js_reset. After adding it, codex mcp list shows node_repl as an enabled stdio server.

    This does not change the underlying bug report: Browser Use is enabled, but the required node_repl/js execution 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.

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 workingmcpIssues related to the use of model context protocol (MCP) serverssessionIssues involving session (thread) management, resuming, forking, naming, archiving

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions