Browser Use can be reported unavailable when node_repl/js is deferred but discoverable

Open 💬 0 comments Opened May 7, 2026 by BradenHartsell

What version of the Codex App are you using (From “About Codex” dialog)?

Windows Codex Desktop, exact app build not shown in this run. CLI visible from the same environment:

codex-cli 0.128.0

Relevant features from codex features list:

browser_use       stable  true
in_app_browser    stable  true
tool_search       stable  true

Browser Use plugin observed locally:

browser-use/0.1.0-alpha1
backend = "iab"

What platform is your computer?

Windows desktop app.

What issue are you seeing?

An explicit Browser Use request can be incorrectly reported as blocked when the required Node REPL JavaScript tool is not initially visible, even though it is discoverable and usable through tool_search.

In the affected turn, the agent reported:

Browser Use skill: loaded
browser-client.mjs: present
panel width: repaired to 460
node_repl js tool: not exposed
placeholder mcp__node_repl__js: unsupported

It then concluded that Browser Use could not be driven because the Node REPL js execution tool was unavailable.

That conclusion was wrong for the same environment. In a follow-up turn, running tool discovery for node_repl js JavaScript execution exposed mcp__node_repl__js, and Browser Use initialized successfully:

const { setupAtlasRuntime } = await import("file:///C:/Users/brade/.codex/plugins/cache/openai-bundled/browser-use/0.1.0-alpha1/scripts/browser-client.mjs");
const backend = "iab";
await setupAtlasRuntime({ globals: globalThis, backend });
await agent.browser.nameSession("Browser Use smoke test");
globalThis.tab = (await agent.browser.tabs.selected()) || await agent.browser.tabs.new();

Result:

{
  "ok": true,
  "title": "about:blank",
  "url": "about:blank"
}

Why this looks distinct from existing node_repl availability issues

There are several related issues where node_repl/js is genuinely missing from a thread or cannot be injected, for example #21301, #20579, #20417, #19365, and #19368.

This report is narrower: in this case the tool was not visible at first, but it was discoverable and functional through tool_search in the same session. The failure mode is that the agent can treat the initially visible tool list as final, try or mention a placeholder name, and report a hard blocker without first exposing the deferred MCP tool.

Expected behavior

If Browser Use is enabled and the Browser Use skill requires node_repl/js, Codex should make that dependency harder to miss. Any of these would avoid this failure mode:

  1. Automatically expose node_repl/js when the Browser Use skill is loaded or selected.
  2. Allow skills/plugins to declare MCP tool dependencies that are surfaced before the agent needs them.
  3. Make the model/tooling path explicitly fail with “required deferred tool was not searched for” rather than allowing a final answer that says the tool is unavailable.
  4. Treat js_reset visible without js visible as a strong signal to run tool discovery for node_repl js.

Steps to reproduce

  1. Start a Windows Codex Desktop thread with Browser Use and the in-app browser enabled.
  2. Ask the agent to use Browser Use / the in-app browser.
  3. Ensure tool_search is available but mcp__node_repl__js is not initially visible in the direct tool list.
  4. Observe that the agent can report Browser Use blocked because node_repl js is not exposed.
  5. In a later turn, search for node_repl js JavaScript execution through tool discovery.
  6. Observe that mcp__node_repl__js can be exposed and Browser Use can initialize successfully.

Additional information

A local instruction workaround was added to the Browser Use skill text to force discovery before reporting Browser Use blocked, but this feels like a product/runtime dependency exposure issue rather than something each user should have to patch locally.

View original on GitHub ↗