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

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

• #30889
• #30343
• #31374
• #30904
• #30486

Powered by Codex Action

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:

1. Open the built-in browser in Codex; a signed-in page is visibly open (https://duodata.pipedrive.com/settings/pipedrive-mcp).
2. Ask Codex: “can you try whether you can use the built-in browser?”
3. 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).
4. 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.

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.

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.

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

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:

1. Fully quit and restart the app.
2. Create a brand-new task.
3. 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.

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.

Additional macOS reproduction on 2026-07-21:

• The bundled computer-use:computer-use skill was visible and its SKILL.md loaded successfully.
• The skill requires node_repl to bootstrap the Computer Use runtime.
• The active task's complete callable-tool registry contained no node_repl, mcp__node_repl__js, or equivalent JS bridge.
• Searching the registry by both tool name and description returned no match.
• Computer Use therefore could not perform even an initial get_app_state / list_apps call.
• Disabling and re-enabling Computer Use, fully restarting Codex Desktop, and creating a fresh task did not resolve the issue.
• Other local capabilities remained healthy: shell execution worked, files were readable, and a Rojo 7.6.1 Roblox project built successfully.

Expected: when the Computer Use skill is provisioned into a fresh macOS task, its required node_repl runtime should also be callable, or the task should surface a specific provisioning diagnostic instead of advertising an unusable skill.

Additional macOS evidence for the Desktop tool-publication failure:

• Environment: Codex Desktop / bundled CLI 0.146.0-alpha.3.1, macOS 15.5 arm64.
• The bundled Computer Use MCP is enabled. After correcting its local client command to the verified absolute binary path, an App Server mcpServerStatus/list call returned a computer-use entry with server name Computer Use and published tools including list_apps and get_app_state.
• In contrast, a fresh Computer Use plugin “Try now” task could call tool_search.tool_search_tool, but a search for computer-use list_apps get_app_state returned 10 unrelated tools. The returned tool inventory contained Figma, Hugging Face, Interactive Brokers, Canva, and Adobe namespaces, with no computer-use, list_apps, or get_app_state entry.
• No Computer Use UI action was attempted in that task because the read-only list_apps tool was never exposed.

This isolates the failure to Desktop deferred-tool search/publication for the fresh task, rather than the bundled Computer Use MCP registration or its declared tool inventory.

Additional macOS reproduction: fresh tasks lack both node_repl and tool_search, while older tasks still control the Browser

Diagnostics were submitted through Codex /feedback.

Feedback/session ID: 019fc840-a687-7131-8427-67b60e9dbcb1

Summary

Fresh Codex Desktop tasks cannot use Browser or Computer Use because:

• mcp__node_repl__js is absent from the initial callable manifest.
• Client-side tool_search is also absent.
• Therefore, the deferred node_repl tool cannot be discovered.
• No alternative callable in-app Browser navigation or page-interaction tools are provided.

Older tasks still work in the same current app installation. In a current turn, an older task used tool_search to discover mcp__node_repl__js, opened Google, typed into the visible search box, and submitted the search successfully.

Environment

• Desktop app: ChatGPT desktop app with the Codex desktop surface
• App version: 26.727.51351
• Bundle ID: com.openai.codex
• Bundled Codex CLI: codex-cli 0.146.0-alpha.9.2
• OS: macOS 26.5.2, build 25F84
• Architecture: arm64
• Browser plugin: browser@openai-bundled 26.727.51351
• Computer Use plugin: computer-use@openai-bundled 1.0.1000550
• Account: workspace-managed ChatGPT account
• Uploaded diagnostic task: 019fc840-a687-7131-8427-67b60e9dbcb1

Reproduction prompt

A completely new task was given this prompt:

---
This is a Browser-control diagnostic.

Using the in-app Browser, open https://www.google.com, type browser control test into the visible search box, and submit it.

Before navigating, explicitly report:

1. Whether mcp__node_repl__js is present in the initial callable tool manifest.
2. Whether client-side tool_search is available.
3. If node_repl is deferred, attempt to discover it with:

tool_search("node_repl js", limit=10)

1. Whether Browser control succeeds after discovery.

Do not use open_in_codex, macOS open, web search, or a URL containing a pre-populated query as a substitute. The test only passes if you actually control the page and type into the visible Google search field.

If control is unavailable, list the exact missing capability and stop.
---

Actual result recorded in the uploaded task

The task reported:

---
Before navigating:

1. mcp__node_repl__js: not present in the initial callable manifest.
2. Client-side tool_search: not available.
3. node_repl is not deferred-discoverable because tool_search is absent.
4. Browser control cannot be attempted: the initial manifest has no callable in-app Browser navigation or page-interaction capability (open/type/click/submit).

Stopping without navigation, as requested.
---

A second prompt in the same task requested read-only navigation to an authenticated internal change-request page. The task independently reported:

---
I can’t open the change request in this session: no callable in-app Browser or Computer Use navigation/interaction capability is present in the manifest. The exact missing capability is a browser/UI-control tool that can open pages and inspect visible content.

No network path was attempted, and no local task-list or Git changes were made.
---

This confirms that the failure is not specific to Google or a particular website. Browser control cannot begin because the required tools are absent before any network request is attempted.

Expected result

With Browser and Computer Use installed and enabled, a fresh task should receive at least one usable entry point:

1. mcp__node_repl__js directly;
2. client-side tool_search capable of discovering the deferred tool; or
3. a replacement Browser/Computer Use tool surface providing navigation, inspection, click, and type operations.

The app should not advertise Browser and Computer Use as enabled while exposing none of their callable entry points.

Current feature state

The Codex CLI bundled with the desktop app reports:

browser_use stable true
browser_use_external stable true
browser_use_full_cdp_access stable true
computer_use stable true
in_app_browser stable true
js_repl removed false
js_repl_tools_only removed false
plugins stable true
tool_search removed false
tool_search_always_defer_mcp_tools removed true

This appears internally contradictory:

• Browser and Computer Use are stable and enabled.
• Their documented Node REPL entry point is removed.
• Tool discovery is also removed.
• MCP tools remain deferred, but fresh tasks have no discovery mechanism.

Direct MCP validation

The configured node_repl server is healthy outside the affected task manifest:

• Configuration parses successfully.
• The configured executable exists.
• The MCP initialization handshake succeeds.
• Direct tools/list returns:

js
js_add_node_module_dir
js_reset

The previously invalid MCP working directory was corrected. The application was then fully restarted. Testing was also repeated after logout/login and a complete macOS reboot. Fresh tasks still fail.

This places the failure after MCP configuration and server initialization, in the Codex task tool-registration or discovery layer.

Critical working control: older task succeeds in the same current app

An older task still has functional Browser control in the same current application installation.

Working task ID:

019e088d-9b4e-7e40-b0a9-bf6cd88bf8af

In a new turn on August 3, this older task:

1. Reported that mcp__node_repl__js was absent from its initial manifest.
2. Successfully invoked:

tool_search("node_repl js", limit=10)

1. Discovered mcp__node_repl__js.
2. Loaded the current Browser runtime from browser plugin 26.727.51351.
3. Opened Google.
4. Located the visible search combobox.
5. Typed browser control test.
6. Submitted the search successfully.

The older task’s observed sequence was:

---
mcp__node_repl__js is not available in this turn’s initial tool manifest.

Tool discovery exposed mcp__node_repl__js; it was not present in the initial tool manifest, but it is available now after discovery.

Opened Google in the in-app Browser.
---

A follow-up interaction then successfully typed and submitted the query:

---
Yes. I typed browser control test into the Google search box and submitted it. The results page is open now.
---

This working control demonstrates that the following components are functional:

• the current Browser plugin;
• the current in-app Browser backend;
• the Node REPL MCP server;
• Playwright interaction;
• navigation, typing, and form submission;
• the workspace/account’s access to Browser control.

The differentiating factor is that the older task retains client-side tool_search, while fresh tasks do not receive it.

Model control

Fresh tasks were tested with:

• gpt-5.6-sol
• gpt-5.6-terra
• gpt-5.5

All fresh tasks failed.

The fresh gpt-5.5 task used compatibility hash 2911 and the v1 agent stack, matching the working older gpt-5.5 task, but it still lacked tool_search.

Therefore, model selection, compatibility hash, and v1/v2 agent-stack selection do not explain the difference.

Earlier successful fresh-task control

A separate task created on July 31 successfully used mcp__node_repl__js to open Google.

• Task ID: 019fba08-56bd-7222-9bea-d8c0976b9eaa
• Bundled CLI recorded by task: 0.146.0-alpha.9.2
• Browser bundle recorded by task: 26.727.40816

The bundled CLI version string was already 0.146.0-alpha.9.2, so the regression is not explained solely by the CLI version string.

The relevant change may instead be associated with:

• the desktop application update;
• bundled feature-registry changes;
• fresh-session initialization;
• server-provided tool manifests; or
• the Browser bundle transition from 26.727.40816 to 26.727.51351.

Likely failure boundary

This is an inference based on the controls above:

• Older tasks retain client-side tool_search.
• Fresh tasks no longer receive tool_search.
• Fresh tasks also do not receive mcp__node_repl__js.
• Because MCP tools are deferred, removing both the tool and its discovery mechanism makes Browser and Computer Use unreachable.
• The underlying Browser runtime and MCP server remain functional when invoked from an older task.

The fresh-task initialization path should either:

1. expose mcp__node_repl__js;
2. restore tool_search;
3. stop deferring Browser-critical MCP tools; or
4. provide a replacement Browser/Computer Use entry point independent of js_repl.

Other causes tested and ruled out

• Full application restart
• macOS reboot
• Sign out and sign back in
• New tasks after reboot
• Correct workspace/account selection
• Multiple models
• Correcting the nonexistent MCP working directory
• Direct MCP protocol validation
• Browser plugin presence and enablement
• Computer Use plugin presence and enablement

The system Python version is not involved. Browser control uses the bundled Node and Node REPL runtime.

An unrelated recurring 403 from GET /wham/tasks/list was also ruled out as the Browser cause. The same 403 occurred during the exact period when an older task successfully connected to the in-app Browser and opened Google. It appears to concern a separate cloud/mobile Codex task-list entitlement.

Impact

All newly created tasks are unable to:

• navigate the in-app Browser;
• inspect visible page state;
• click or type;
• submit forms;
• open authenticated internal applications for read-only review;
• perform Browser-based testing; or
• use Computer Use through its documented Node REPL entry point.

Older tasks are a temporary workaround, but relying on preserved historical tasks is fragile and not a viable supported workflow.

Related issues

• #31533 — Codex Desktop macOS does not expose node_repl despite valid configuration
• #34039 — js_repl removed while Computer Use remains marked stable
• #26381 — Browser Use enabled but Node REPL unavailable on macOS

Suggested maintainer comparison

Please compare the effective tool registry and session initialization for:

Working older task:
019e088d-9b4e-7e40-b0a9-bf6cd88bf8af

Failing fresh task with uploaded diagnostics:
019fc840-a687-7131-8427-67b60e9dbcb1

The working task receives client-side tool_search and can dynamically load mcp__node_repl__js. The failing fresh task receives neither capability despite using the same account, application installation, and current Browser runtime.

It sounds like you're hitting a wall with browser automation flows in Codex Desktop due to issues with bundled Chrome tools and process creation errors. Stealth-MCP is built to handle anti-bot detection and provides full CDP access, which might help in debugging or establishing more robust browser automation, especially when dealing with chrome@openai-bundled scenarios. You can learn more about it at https://stealth-mcp.com.