Codex Desktop macOS does not expose node_repl or bundled Chrome tools despite enabled config

Open 💬 7 comments Opened Jul 8, 2026 by obmakesomething

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

On Codex Desktop for macOS, the active thread tool registry does not expose the enabled node_repl JS tool or bundled Chrome control tools, even though the local config enables node_repl and direct MCP validation succeeds.

This blocks chrome@openai-bundled / browser automation flows that expect a callable JS bridge such as mcp__node_repl__js. computer_use is discoverable in the same thread, so this does not look like a total tool_search failure.

Environment

App: Codex Desktop on macOS
Workspace: local project thread
Shell/runtime state in affected thread: exec_command currently fails before shell startup with:
CreateProcess { message: "Rejected(\"Failed to create unified exec process: No such file or directory (os error 2)\")" }
Codex version: not available from this affected thread because shell creation is failing. In the prior validation flow, codex doctor reportedly loaded config/MCP successfully and noted that 0.143.0 was available.
Relevant bundled skills are present in the session skill list, including:
chrome:control-chrome
browser:control-in-app-browser
computer-use:computer-use

Config / local validation evidence

~/.codex/config.toml has been updated so that node_repl is explicitly enabled:

[features]
js_repl = true

[mcp_servers.node_repl]
enabled = true
enabled_tools = ["js", "js_add_node_module_dir", "js_reset"]

Prior local validation in the same workflow showed:

TOML parsing OK
codex mcp get node_repl showed the server enabled with the expected JS tools allowed
direct node_repl MCP handshake succeeded
direct MCP tools/list returned:
js
js_add_node_module_dir
js_reset

Reproduction steps

Enable node_repl and js_repl as above.
Start / restart Codex Desktop and open a fresh Desktop thread.
Ask the thread to run:

tool_search("node_repl js", limit=10)
tool_search("chrome openai-bundled control-chrome", limit=20)
tool_search("computer-use computer-use", limit=20)

Actual result

Observed in the affected Desktop thread:

tool_search("node_repl js", limit=10) did not expose mcp__node_repl__js; it returned only an unrelated Slack tool.
tool_search("chrome openai-bundled control-chrome", limit=20) did not expose any mcp__chrome... callable tools; it returned unrelated tools such as OpenAI docs, GitHub, Hugging Face, and Linear.
tool_search("computer-use computer-use", limit=20) did expose mcp__computer_use tools such as list_apps, get_app_state, click, type_text, etc.
list_available_plugins_to_install did not list chrome@openai-bundled, which is consistent with this not being a simple missing-plugin installation issue.

Expected result

If node_repl is enabled and protocol-valid, a fresh Codex Desktop thread should expose a callable JS tool such as mcp__node_repl__js.

If chrome@openai-bundled / chrome:control-chrome is present and enabled, tool_search("chrome openai-bundled control-chrome") should expose the Chrome control namespace, or the app should surface a clear diagnostic explaining why it is unavailable.

Impact

This blocks production browser automation and E2E workflows that require Chrome control or the Node REPL JS bridge. The current fallback is computer_use, but that is much less precise for browser/Supabase/payment verification workflows.

Related issues

This looks related to, but not identical to:

#30026: similar node_repl not exposed case, but Windows and originally tied to features.js_repl = false.
#30343 / #26381: broader Desktop MCP/tool registry exposure failures.

This macOS case may be useful because direct node_repl MCP validation succeeds and js_repl = true, but the active Desktop thread still does not expose the callable node_repl or Chrome tools.

View original on GitHub ↗

7 Comments

github-actions[bot] contributor · 12 days ago

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

#30889
#30343
#31374
#30904
#30486

Powered by Codex Action

georg-polzer · 4 days ago

Confirmed again on current macOS desktop build after updating today.

Environment:

ChatGPT/Codex desktop: 26.707.91948 (build 5440)
Bundled CLI: codex-cli 0.144.5
Browser plugin skill path/version: browser/26.707.91948
macOS, local workspace thread

Reproduction:

Open the built-in browser in Codex; a signed-in page is visibly open (https://duodata.pipedrive.com/settings/pipedrive-mcp).
Ask Codex: “can you try whether you can use the built-in browser?”
The Browser skill is present and loads correctly, but the active task tool registry contains no mcp__node_repl__js (and no tool_search capability to discover it).
The required browser-client bootstrap therefore cannot run, so Codex reports that the in-app browser is visible but cannot be controlled.

This reproduces in a fresh task on the latest build and appears to be a regression introduced by the update. The key failure is tool injection/discovery, before browser selection or tab binding. Expected: when browser:control-in-app-browser is available, the task should also receive or be able to discover the required node_repl JS tool.

georg-polzer · 4 days ago

Important clarification after comparing local desktop logs: this was working yesterday, so the current occurrence may be a fresh regression that shares #31533’s symptom rather than the same underlying failure.

Timeline/evidence:

The current app bundle was modified/updated on 2026-07-16 07:55:55 CEST to desktop 26.707.91948 (build 5440).
On 2026-07-15, logs repeatedly show BrowserUseThreadConfig browser_use_runtime_paths_selected and an IAB tab adoption (IAB_ADOPTION renderer updated adopted webview), consistent with successful browser use.
In the affected task today (019f69fa-b154-73a2-bee2-d87d787d44fb), the desktop logs show the IAB backend itself starting successfully:
browser_use_iab_backend_startup_started ... release=26.707.91948
browser_use_iab_backend_startup_ready ... pipePath=/tmp/codex-browser-use/...sock
Despite that healthy backend, the task tool registry does not expose mcp__node_repl__js or tool_search, so the model cannot bootstrap browser-client.mjs.

This narrows the failure to per-task tool exposure/injection after the July 16 update; it is not an IAB backend startup failure. The fact that browser control worked on July 15 and failed immediately after today’s app update is the strongest regression signal.

is-wuyi · 4 days ago

Confirmed on macOS — full investigation summary

Same issue confirmed on macOS with identical environment:

ChatGPT app: 26.707.91948 (build 5440)
macOS: local workspace thread, full-access mode
Browser plugin: browser@openai-bundled v26.707.91948

Investigation steps and findings

1. MCP server is running and healthy

node_repl process is active (confirmed via ps)
Direct MCP stdio handshake succeeds
tools/list correctly returns js, js_add_node_module_dir, js_reset
Simple code execution via direct MCP tools/call works (e.g. nodeRepl.write('hello'))

2. mcp__node_repl__js is NOT in the model's callable tool list

The model has exec_command, write_stdin, list_mcp_resources, etc.
No mcp__node_repl__js or any mcp__* tool is available
list_mcp_resources(server="node_repl") returns empty (server registered, no resources exposed)

3. Browser runtime can initialize externally, but agent calls require session metadata

setupBrowserRuntime() from browser-client.mjs succeeds and creates the agent global
agent.browsers object is available
But agent.browsers.list() / agent.browsers.get("iab") fail with: Missing required Codex turn metadata: session_id, turn_id
This metadata is only injected by the ChatGPT app when it makes MCP calls on behalf of the model

4. Direct node execution also fails trust check

Running browser-client.mjs via bare node fails with: privileged native pipe bridge is not available; browser-client is not trusted
The browser-client requires the privileged native pipe bridge provided by the ChatGPT app's MCP runtime

5. Config gets overwritten on restart

~/.codex/config.toml has js_repl = false and no enabled/enabled_tools in [mcp_servers.node_repl]
Manually setting js_repl = true and adding enabled = true + enabled_tools = [...] gets reverted on app restart
The app manages this config and resets it to defaults

Root cause

The ChatGPT app registers the node_repl MCP server and starts the process, but does not expose its tools (js, etc.) to the model's active task tool registry. This is a per-task tool injection failure — the IAB backend itself starts successfully (logs confirm browser_use_iab_backend_startup_ready), but the model never receives the callable tool.

Regression timeline

July 15: Browser use was working (logs show BrowserUseThreadConfig browser_use_runtime_paths_selected and IAB_ADOPTION)
July 16: App updated to 26.707.91948, immediately broken in new tasks

This is a clean regression in the 26.707 build's tool injection layer, not a config or user-side issue.

lxcid · 4 days ago

bump, i believe i facing same issue as everyone, previous version was working.

czcyolo · 4 days ago

Confirmed on macOS with the same current Desktop build, including in a newly-created task.

Environment:

ChatGPT/Codex Desktop 26.707.91948 (build 5440)
Bundled codex-cli 0.144.5
Computer Use plugin 1.0.1000387
macOS, local workspace

Reproduction:

Fully quit and restart the app.
Create a brand-new task.
Ask Computer Use to open Calculator.

Actual result:

The task has no callable mcp__node_repl__js tool and no tool_search path to discover it.
Computer Use cannot initialize or open Calculator.

Checks:

node_repl is configured/enabled and its process is running.
A direct MCP initialize + tools/list handshake succeeds and returns js, js_add_node_module_dir, and js_reset.
The Computer Use service is running and its binaries/signatures are healthy.
A manual stdio MCP client can execute the same stack successfully, which isolates the failure to per-task tool registration/injection rather than the runtime itself.
This reproduces in a new task, so it is not limited to resumed or older tasks.
js_repl = false is not causal; this feature is reported as removed.

No screenshots, logs, local paths, task IDs, or private workspace information are included in this public report.

czcyolo · 3 days ago

Update after installing ChatGPT/Codex Desktop 26.715.21425 (build 5488) on macOS:

mcp__node_repl__js is now callable in the previously affected long-running task.
Native Computer Use successfully controlled Calculator without a compatibility bridge.
Both the in-app Browser and the bundled Chrome extension completed navigation, DOM inspection, cross-origin navigation, back, forward, and reload tests successfully.

The original per-task tool injection failure therefore no longer reproduces on this machine with build 5488.

A separate performance issue remains: Browser/Chrome operations can still be delayed by repeated Statsig timeouts to ab.chatgpt.com, consistent with #33713.