›_ Codex Issues
Codex Issues / #38549

[macOS Desktop] In-app Browser control unavailable because bundled node_repl MCP client never becomes ready

Open 💬 4 comments Opened Aug 14, 2026 by Dean1991911
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using?

Codex Desktop 26.803.61601 (build 6396), Chromium 151.0.7922.76.

Platform

macOS, Apple Silicon (arm64).

What issue are you seeing?

The in-app Browser opens pages normally, but Codex cannot inspect, click, type, or otherwise control the page because the bundled Browser/Computer Use MCP tool is absent from the task.

The same setup worked on 2026-08-13. Beginning on 2026-08-14, Browser control stopped working and remains unavailable after fully quitting and restarting Codex multiple times.

Local logs repeatedly show:

omitting MCP server without an exact ready client server_name=node_repl

The previous working session logged successful initialization of the same service:

server_name=node_repl ... Service initialized as client ... version 1.5.0

Other MCP services initialize normally in the failing sessions. The bundled Browser plugin is enabled, its files are present, the configured node_repl executable exists and responds to --help, and the target web origin is allowed. No Browser/Computer Use tool is exposed to the task.

No private page content, credentials, complete configuration files, or raw log database are attached publicly.

Steps to reproduce

  1. Open Codex Desktop on macOS.
  2. Open a page in the in-app Browser.
  3. In a task, reference Browser and ask Codex to inspect the current page title or click/type on the page.
  4. Observe that no Browser/Computer Use MCP tool is available.
  5. Fully quit Codex Desktop and reopen it.
  6. Create a new task and repeat.
  7. Observe that the failure persists and the log contains:

omitting MCP server without an exact ready client server_name=node_repl.

Expected behavior

The bundled node_repl MCP client should initialize and expose the Browser/Computer Use tools, allowing Codex to inspect and interact with the in-app Browser.

Actual behavior

The in-app Browser renders pages, but the control bridge never becomes ready. Codex omits the node_repl server from the tool catalog, so page inspection and interaction are impossible.

Additional information

  • This worked on the same installation on 2026-08-13.
  • It failed on 2026-08-14 without an intentional configuration change.
  • Full application restarts do not recover it.
  • The target site's login and page rendering still work; only the control interface is unavailable.
  • Related but not identical: #38342 (plugin skill present while its stdio MCP tools are absent). This report concerns the bundled Browser/Computer Use node_repl service.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 14 days ago

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

  • #37976

Powered by Codex Action

andrsksr · 12 days ago

Additional reproduction from macOS, observed during a long-running end-to-end product test.

Environment:

  • Codex Desktop 26.810.41047 (build 6570)
  • macOS 26.3 (25D125), Apple Silicon arm64
  • Bundled Browser and Chrome plugin cache: 26.810.41047

Timeline:

  • Browser control was stable for several weeks through August 13, 2026.
  • The failure began on August 14, 2026, without an intentional configuration change.

Observed behavior:

  • The in-app Browser renders the page normally.
  • The Browser backend discovers the exact visible tab and returns its URL and provider tab identifier.
  • Claiming or attaching to that tab then times out after approximately 15 seconds, so inspection, clicks, typing, screenshots, and navigation through the control API are unavailable.
  • The Chrome backend is also only partially functional: tab listing or opening can succeed, while tab selection, retrieval, and closing time out.
  • The site itself remains reachable and authenticated. The failure is isolated to the browser-control handoff.

Recovery attempts without durable success:

  • Full restarts of Codex Desktop, Chrome, and macOS
  • New browser tabs and a separate Chrome profile
  • Reloading the Chrome extension
  • Closing unnecessary tabs
  • Pruning stale Browser and Computer Use worker processes before retrying

Impact:
This blocks a production-like end-to-end test that requires an owner session in Chrome and a member session in the in-app Browser. The application under test remains healthy; only the Codex browser-control layer is unavailable.

This appears closely related to this issue, although the failure point in this reproduction is slightly later: the browser tooling is exposed and the backend can discover the visible tab, but it cannot claim or control it. No private URLs, account identifiers, or page contents are included here.

Dean1991911 · 12 days ago

Additional reproduction from macOS

Observed during a long-running end-to-end product test.

Environment
  • Codex Desktop 26.810.41047 (build 6570)
  • macOS 26.3 (25D125), Apple Silicon arm64
  • Bundled Browser and Chrome plugin cache: 26.810.41047
Timeline
  • Browser control was stable for several weeks through August 13, 2026.
  • The failure began on August 14, 2026, without an intentional configuration change.
Observed behavior
  • The in-app Browser renders the page normally.
  • The Browser backend discovers the exact visible tab and returns its URL and provider tab identifier.
  • Claiming or attaching to that tab then times out after approximately 15 seconds, so inspection, clicks, typing, screenshots, and navigation through the control API are unavailable.
  • The Chrome backend is also only partially functional: tab listing or opening can succeed, while tab selection, retrieval, and closing time out.
  • The site itself remains reachable and authenticated. The failure is isolated to the browser-control handoff.
Recovery attempts without durable success
  • Full restarts of Codex Desktop, Chrome, and macOS
  • New browser tabs and a separate Chrome profile
  • Reloading the Chrome extension
  • Closing unnecessary tabs
  • Pruning stale Browser and Computer Use worker processes before retrying
Impact

This blocks a production-like end-to-end test that requires an owner session in Chrome and a member session in the in-app Browser. The application under test remains healthy; only the Codex browser-control layer is unavailable.

This appears closely related to this issue, although the failure point in this reproduction is slightly later: the browser tooling is exposed and the backend can discover the visible tab, but it cannot claim or control it.

No private URLs, account identifiers, or page contents are included here.

vemelianov-aplus · 3 days ago

Additional reproducible data point from macOS, specifically involving an existing thread.

Environment:

  • macOS 26.5.2, Apple Silicon (arm64)
  • Codex/ChatGPT Desktop 26.818.61809 (build 7019)
  • Bundled Browser plugin 26.818.61809
  • Thread ID: 01a03285-260b-7ce3-bebd-7a6070d9afa1

Observed sequence:

  1. Continued an existing Codex thread that had not started with Browser attached.
  2. Selected and sent [@Browser](plugin://browser@openai-bundled) from the UI.
  3. The Browser skill/instructions were injected successfully, and the app explicitly reported the Browser plugin capability.
  4. The active task still did not expose mcp__node_repl__js; tool discovery contained no node_repl entry.
  5. A subsequent turn with Browser explicitly attached had the same result, so the agent could not bootstrap browser-client.mjs or control the in-app browser.

Local installation checks:

  • browser-client.mjs exists in the bundled plugin cache.
  • App and Browser plugin versions match.
  • Desktop logs report browser_use_runtime_paths_selected with bundled node_repl, Node v24.19.0, and nodeVersionStatus=ok.
  • The failure is therefore at tool/runtime attachment: the UI and skill layer recognize Browser, but the callable node_repl bridge is absent from the task.

Expected behavior:

Attaching Browser to an existing thread should either expose the required node_repl tool on the next turn, or the UI should clearly state that the thread must be recreated. A selectable plugin mention should not produce a skill-only state with no executable control tool.

No private URLs, repository contents, credentials, or raw logs are included.