Repository navigation
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 #33599
Description
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 #25361 / #24297 / #21301 / #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-sidecodex_appsentries back. Thenode_repljstool was never present in the task, so no browser call was ever attempted. - The
node_replserver itself is healthy: launching/Applications/ChatGPT.app/Contents/Resources/cua_node/bin/node_replmanually over stdio, with the exact command and env from the app-written[mcp_servers.node_repl]block in~/.codex/config.toml, answersinitializeand listsjs,js_add_node_module_dir,js_reset;jsexecutes code normally. - The browser client stack works: driving
browser-client.mjsthrough 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 withBrowser 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
codexsession (CLI0.144.5) reading the same~/.codex/config.tomlshowsnode_replwithjs/js_add_node_module_dir/js_resetin/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.codexshowsBrowserUseThreadConfig browser_use_runtime_paths_selectedwith correct bundled paths, thenIAB_LIFECYCLE captured session route, then nothing —node_replis 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
- Codex Chrome Plugin: extension-host not running, node_repl MCP tool unavailable in session #25361 — Chrome plugin: extension-host not running, node_repl MCP tool unavailable in session (includes a 2026-07-16 repro on these exact builds)
- node_repl: tools/list returns js but runtime routes mcp__node_repl__js as unsupported call #24297 — direct MCP
tools/list/tools/callwork, but the runtime doesn't expose/route the tool - Browser Use node_repl/js availability diverges by thread in Codex Desktop #21301 — Browser tooling appears in one task, disappears in another
- Browser Use broken after today update: no node_repl/js or no Codex IAB backend discovered #20579 — broader open Browser/node_repl issue with multiple macOS reproductions
Activity
github-actions commentedon Jul 16, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
colindotfun commentedon Jul 16, 2026
Follow-up — controlled comparison isolating the regression further. I installed the last pre-merge standalone Codex desktop app (
26.623.141536, the discontinuedcodex-appbuild) 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_replfine standalone, the CLI injects it fine).jeygeethan-dev commentedon Jul 16, 2026
I have the same issue but I saw that the macOS codex app is at
26.707.91948while the Settings -> Configuration -> Workspace Dependencies -> Current Version:26.715.12143. I am thinking this discrepancy could be the issue?jeygeethan-megan commentedon Jul 16, 2026
Additional diagnostics: in my environment this is not limited to Desktop; it also reproduces in the bundled terminal CLI.
Environment:
26.707.919480.144.526.715.1214326.5.2In the CLI,
/mcpreportsnode_repland listsjs,js_add_node_module_dir, andjs_reset. The server initializes successfully asrmcp 1.5.0withtool_count=3, and a direct MCPtools/callusingconsole.log(1+1)returns2withisError:false.However, a fresh CLI task receives no callable
node_repltool. 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 showselected_capability_root_count=0even 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 includedToolSearchAlwaysDeferMcpTools. 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:
019f6b83-c573-75a3-a1a6-6462d6bc4801019f6b86-a58f-7a12-bf38-81c34a339119019f6b89-b419-7351-b518-3ca71d4c81a2019f6a86-bbab-7a51-9716-cc22a6432f65This 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 commentedon Jul 16, 2026
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:
mcp__node_replnamespace withjs,js_add_node_module_dir, andjs_reset.node_repl/jscall runningconsole.log(1+1)returned2.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_calltonode_repl/jsand returned2, while GPT-5.6 Terra still reportednode_replunavailable 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 commentedon Jul 23, 2026
Reproduced on macOS in Codex Desktop on 2026-07-23.
Observed behavior:
chrome/26.715.72359/skills/control-chrome/SKILL.md).node_repl js, including an explicitlimit: 10retry, returned no callablemcp__node_repl__jstool.This matches the issue's central symptom: the plugin/skill can be present while the Desktop task silently receives no
node_replbrowser-control tool. No client or private task data is included here.HaonanChen-2024 commentedon Aug 7, 2026
I can reproduce the same core issue on Windows.
Environment:
Desktop:
CLI control test:
Using the bundled Codex CLI on the same machine with the same config.toml,
/mcpcorrectly shows:node_repl
Tools: js, js_add_node_module_dir, js_reset
I also compared the Desktop and CLI runtime paths/builds:
An older Desktop thread had successfully used
jsmultiple 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 commentedon Aug 26, 2026
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.