Desktop app silently fails to attach node_repl MCP tools to new tasks — breaks Browser (in-app), Chrome, and Computer Use; CLI with the same config works

Open 💬 8 comments Opened Jul 16, 2026 by colindotfun

💡 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 (From "About Codex" dialog)?

26.707.91948

What subscription do you have?

Pro

What platform is your computer?

macOS 27 (pre-release), Apple Silicon

What issue are you seeing?

New Desktop tasks never get the node_repl js tool (or the Computer Use tools) injected, so every plugin that depends on it fails with "control connection / runtime isn't available in this task." The failure is silent — nothing is logged. Every layer beneath task tool-injection is verifiably healthy, and the terminal CLI reading the same ~/.codex/config.toml injects the tool fine.

This looks like the same family as openai/codex#25361 / openai/codex#24297 / openai/codex#21301 / openai/codex#20579, but those are framed around the Chrome plugin or extension chain. This reproduction uses the in-app Browser plugin with no Chrome extension installed at all, which narrows the defect to Desktop task tool-injection itself.

Reproduces on a fully clean install: complete wipe of ~/.codex, all app state (com.openai.chat, com.openai.codex, Application Support, caches, HTTPStorages, preferences), CUA helper containers, and native-messaging manifests → reboot → reinstall via Homebrew → sign in → let the app re-provision plugins from scratch → identical failure on the first test. Restarts, plugin reinstalls, and fresh tasks do not help.

User-visible failure

Desktop task, prompt @Browser open google:

I couldn't open Google because the Browser plugin's control connection isn't available in this task. Please retry after reconnecting the Browser plugin.

Failing thread id 019f6b0d-ec16-7993-b412-66b520793db2 (2026-07-16T13:11Z), in case it helps telemetry. The Computer Use plugin fails the same way in tasks ("its UI-control tool isn't exposed in this task").

Isolation — every layer below Desktop task tool-injection works

Session rollout (~/.codex/sessions/.../rollout-*.jsonl): the model read the Browser SKILL.md, ran tool discovery (list_mcp_resources, list_mcp_resource_templates), and got only account-side codex_apps entries back. The node_repl js tool was never present in the task, so no browser call was ever attempted.
The node_repl server itself is healthy: launching /Applications/ChatGPT.app/Contents/Resources/cua_node/bin/node_repl manually over stdio, with the exact command and env from the app-written [mcp_servers.node_repl] block in ~/.codex/config.toml, answers initialize and lists js, js_add_node_module_dir, js_reset; js executes code normally.
The browser client stack works: driving browser-client.mjs through that manual server (setupBrowserRuntime → agent.browsers.get("iab")), with _meta["x-codex-turn-metadata"] = {session_id, turn_id} supplied, passes the turn-metadata gate and fails only with Browser is not available: iab — expected for a session the Desktop app doesn't own, since the app binds in-app-browser hosts per conversation (browser-session-registry / IAB_LIFECYCLE captured session route conversationId=… in the Desktop logs).
The CLI injects the tool; the Desktop app doesn't: a terminal codex session (CLI 0.144.5) reading the same ~/.codex/config.toml shows node_repl with js / js_add_node_module_dir / js_reset in /mcp. (From the terminal the in-app browser is still unavailable, which looks expected — no app-owned conversation to bind a host to — but tool injection itself works there.)
The failure is silent: for the failing task, ~/Library/Logs/com.openai.codex shows BrowserUseThreadConfig browser_use_runtime_paths_selected with correct bundled paths, then IAB_LIFECYCLE captured session route, then nothing — node_repl is never spawned or attached for the task, and no error, warning, or timeout is logged anywhere.

Possibly related: the app writes its [mcp_servers.computer-use] entry with enabled = false even while the Computer plugin itself is enabled and its helper (com.openai.sky.CUAService) is installed and validly signed.

Related issues

openai/codex#25361 — Chrome plugin: extension-host not running, node_repl MCP tool unavailable in session (includes a 2026-07-16 repro on these exact builds)
openai/codex#24297 — direct MCP tools/list/tools/call work, but the runtime doesn't expose/route the tool
openai/codex#21301 — Browser tooling appears in one task, disappears in another
openai/codex#20579 — broader open Browser/node_repl issue with multiple macOS reproductions

View original on GitHub ↗

8 Comments

github-actions[bot] contributor · 1 month ago

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

#33595
#32720

Powered by Codex Action

colindotfun · 1 month ago

Follow-up — controlled comparison isolating the regression further. I installed the last pre-merge standalone Codex desktop app (26.623.141536, the discontinued codex-app build) on the same machine, same macOS version, same account, same day, after an identical full state wipe. Both the in-app Browser and Computer Use work perfectly there.

Identical OS, account, and local environment — only the app generation differs. That rules out OS incompatibility and account-side rollout flags, and pins the regression on the merged ChatGPT Desktop app's task runtime, consistent with the isolation above (every layer beneath tool-injection healthy: node_repl fine standalone, the CLI injects it fine).

jeygeethan-dev · 1 month ago

I have the same issue but I saw that the macOS codex app is at 26.707.91948 while the Settings -> Configuration -> Workspace Dependencies -> Current Version: 26.715.12143. I am thinking this discrepancy could be the issue?

jeygeethan-megan · 1 month ago

Additional diagnostics: in my environment this is not limited to Desktop; it also reproduces in the bundled terminal CLI.

Environment:

Codex app: 26.707.91948
Bundled CLI: 0.144.5
Workspace Dependencies: 26.715.12143
macOS: 26.5.2

In the CLI, /mcp reports node_repl and lists js, js_add_node_module_dir, and js_reset. The server initializes successfully as rmcp 1.5.0 with tool_count=3, and a direct MCP tools/call using console.log(1+1) returns 2 with isError:false.

However, a fresh CLI task receives no callable node_repl tool. The model reports it as unavailable without attempting a tool call and without receiving an MCP error. A fresh Desktop task fails the same way. The corresponding logs show selected_capability_root_count=0 even though the MCP manager discovered all three tools.

I also launched the CLI with --disable tool_search_always_defer_mcp_tools, but the resulting session logs still included ToolSearchAlwaysDeferMcpTools. Therefore that user-facing override was ineffective in this build and did not produce a valid enabled-vs-disabled comparison.

Task IDs for telemetry correlation:

Fresh Desktop: 019f6b83-c573-75a3-a1a6-6462d6bc4801
CLI normal launch: 019f6b86-a58f-7a12-bf38-81c34a339119
CLI with the attempted disable override: 019f6b89-b419-7351-b518-3ca71d4c81a2
Original Desktop task where the tool was available earlier and later disappeared: 019f6a86-bbab-7a51-9716-cc22a6432f65

This appears to broaden the failure from Desktop-specific browser attachment to the shared runtime tool-exposure/injection layer. It seems closely related to #24297, although in these tasks the tool is silently omitted rather than routed as an unsupported call.

jeygeethan-megan · 1 month ago

Follow-up: confirmed model-switch workaround on the same environment.

All of my failing Desktop and CLI tests used gpt-5.6-sol. I changed only the model to GPT-5.4 and started a genuinely new Desktop task; there were no app, plugin, MCP, or configuration changes between the failing and working tests.

On GPT-5.4:

Tool discovery exposed the mcp__node_repl namespace with js, js_add_node_module_dir, and js_reset.
A real node_repl/js call running console.log(1+1) returned 2.
The Chrome plugin then connected successfully and performed a read-only listing of the currently open tabs.

Working Desktop task ID for telemetry correlation: 019f6b99-ac95-7a12-a702-4a158ec39c06.

I also ran equivalent ephemeral CLI probes. GPT-5.4 produced a real mcp_tool_call to node_repl/js and returned 2, while GPT-5.6 Terra still reported node_repl unavailable in that CLI test. Terra may therefore be surface/session dependent in this environment, but GPT-5.4 is confirmed working in both the CLI probe and a fresh Desktop task.

This strongly supports the model/tool-exposure regression described in #33575 rather than a broken Chrome extension, MCP server, or local configuration. Current practical workaround here: select GPT-5.4 and create a fresh task.

jeroenr71 · 1 month ago

Reproduced on macOS in Codex Desktop on 2026-07-23.

Observed behavior:

The bundled Chrome skill is present (chrome/26.715.72359/skills/control-chrome/SKILL.md).
The skill-required JavaScript execution tool is not injected into the task.
Repeated tool discovery for node_repl js, including an explicit limit: 10 retry, returned no callable mcp__node_repl__js tool.
As a result, the official Chrome plugin/browser-client path could not be initialized or used to list/control existing Chrome tabs.
Restarting/reinstalling and retrying from a fresh task did not resolve the issue.
Direct macOS automation could still read and control the same Chrome installation and its tabs, which suggests Chrome itself was healthy and narrows the failure to Codex Desktop task tool injection / trusted browser bridge provisioning.

This matches the issue's central symptom: the plugin/skill can be present while the Desktop task silently receives no node_repl browser-control tool. No client or private task data is included here.

HaonanChen-2024 · 21 days ago

I can reproduce the same core issue on Windows.

Environment:

Windows 11
Codex App: 26.803.5235.0
app-server release: 26.803.41515
bundled Codex CLI: 0.147.0-alpha.6.5
runtime build: f1bf3cd3a5929acd

Desktop:

Browser availability = true
IAB backend ready = true
built-in Browser pane opens successfully
node_repl is started by app-server
node_repl MCP initializes successfully with ToolsCapability
but a completely new Desktop thread has:
JS_PRESENT = NO
BROWSER_CONTROL_PRESENT = NO

CLI control test:
Using the bundled Codex CLI on the same machine with the same config.toml, /mcp correctly shows:

node_repl
Tools: js, js_add_node_module_dir, js_reset

I also compared the Desktop and CLI runtime paths/builds:

no stale runtime reference
no Desktop/CLI runtime build skew
Desktop CODEX_CLI_PATH points to the same current bundled codex.exe

An older Desktop thread had successfully used js multiple times in the past, but new Desktop threads no longer receive the tool.

This looks consistent with the Desktop task/tool-injection failure described in this issue rather than a broken node_repl runtime.

Additional note:
I use OpenCodex for model routing, so I cannot completely rule out an interaction with custom routing. However, node_repl tool enumeration itself works correctly in the bundled CLI using the same configuration.

Warubg · 2 days ago

Reproduced again on macOS with ChatGPT/Codex app 26.818.61809 (build 7019), Darwin 25.5.0 arm64, bundled Chrome skill 26.818.61809, and Computer Use skill 1.0.1000854. Chrome is running in the selected Default profile; the official extension/plugin is installed and enabled; and the Native Messaging host is registered. This Desktop task exposes neither node_repl/js nor any Chrome or Computer Use callable tool, so the already-open Chrome tab cannot be inspected or controlled. Reinstalling/re-enabling the plugin and restarting/reopening the app did not restore tool injection. Affected Desktop thread ID for telemetry correlation: 019ffeb7-ab84-7e21-bf03-e6358d33ba9d. No NAS URL, user-file content, account data, cookie, or secret is included.