Windows Desktop: Chrome/Computer Use enabled but mcp__node_repl__js is not exposed; js_repl remains removed false

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

• #30026
• #29229
• #29921

Powered by Codex Action

Thanks for the duplicate check. I reviewed #30026, #29229, and #29921.

#30026 looks like the closest match: same core symptom where Browser/Chrome/Computer Use are installed/enabled, but mcp__node_repl__js / node_repl js is not exposed to the agent session.

This issue adds a current repro on a newer Windows Desktop build:

Codex Desktop: OpenAI.Codex_26.623.5546.0_x64__2p2nqsd0c76g0
Codex CLI: 0.142.3
Bundled Chrome/Browser/Computer Use runtime: 26.623.42026

and confirms the missing-tool behavior persists after:

• rebuilding the bundled plugin cache
• rebuilding the packaged app browser/cache folders
• fresh threads
• checking codex doctor --ascii --all
• attempting the known Administrator workaround

So I agree this is probably the same failure family as #30026/#29229/#29921, but I am leaving this open for now because it confirms the issue still reproduces on 26.623.x and includes the newer diagnostic state where:

browser_use / computer_use = true
node_repl MCP server = enabled
js_repl / js_repl_tools_only = removed false
mcp__node_repl__js = not exposed

Happy to close this as a duplicate of #30026 if maintainers prefer consolidating there.

Same failure observed on a newer Windows Desktop build with additional local remediation attempts.

Environment:

• Windows
• Codex Desktop package: OpenAI.Codex_26.623.8305.0_x64__2p2nqsd0c76g0
• Bundled plugin version: 26.623.61825
• Browser/Chrome/Computer Use plugins enabled in config.toml
• Chrome extension UI shows connected
• Browser settings UI shows Browser enabled/toggleable

Fresh-thread behavior:

• tool_search("node_repl") => 0 results
• tool_search("node_repl js") => 0 results
• Browser/Chrome skills are present locally but cannot be used because mcp__node_repl__js is not exposed.

Additional local checks/remediation performed:

• Rebuilt generated .codex plugin/cache/tmp/browser/computer-use state while preserving auth/sessions/memories/config.
• Removed stale chrome-native-hosts-v2.json entries pointing at older 26.602 / 26.609 resources.
• Removed stale notify hook to a missing old codex-computer-use.exe.
• Repaired broken browser/latest and chrome/latest junctions so both point to real 26.623.61825 cache dirs.
• Copied Browser plugin from current app resources into cache, working around WindowsApps/EFS copy errors.
• Restored current cua_node runtime locally from app resources:
• C:\Users\Administrator\AppData\Local\OpenAI\Codex\runtimes\cua_node\120c650ffb83\bin\node_repl.exe
• SHA256: 88BC2245755492AA3A3365ECCA92EF45F8895867F28A64B1B61DC5FD6D980083

After all of the above, fresh threads still do not expose mcp__node_repl__js.

This suggests the remaining failure is not the plugin cache, Browser/Chrome UI install state, stale native-host metadata, or missing local node_repl.exe; it appears to be in Desktop/app-server tool registration or rollout exposure for the Node REPL JS tool.

I also opened #30562 before GitHub Actions detected this likely duplicate; happy to treat #30486 as the canonical issue.

Follow-up after updating Codex Desktop locally: this appears fixed on my machine.

Updated environment:

Codex Desktop package: OpenAI.Codex_26.623.9142.0_x64__2p2nqsd0c76g0
Codex CLI: 0.142.4
Bundled Chrome/Browser/Computer Use plugin runtime: 26.623.70822
cua_node runtime: still 1b23c930bdf84ed6

After the update, tool discovery for node_repl js exposed the expected MCP server/tools:

mcp__node_repl.js
mcp__node_repl.js_reset
mcp__node_repl.js_add_node_module_dir

Smoke tests passed:

1. Basic Node bridge:

node-repl-smoke-ok

1. Computer Use:

globalThis.apps = await sky.list_apps();

returned running apps/windows, including Chrome and Outlook windows.

1. Chrome extension/browser control:

• setupBrowserRuntime(...) succeeded.
• agent.browsers.get("extension") succeeded.
• browser.documentation() returned the full Chrome/browser API docs.
• Created a temporary tab.
• Navigated to https://example.com/.
• Verified:

{
  "testTabTitle": "Example Domain",
  "testTabUrl": "https://example.com/"
}

• Finalized/cleaned up the test tab.

One notable diagnostic detail: codex features list still reports:

js_repl                              removed            false
js_repl_tools_only                   removed            false

but the bridge now works, so in this newer build that feature-registry line is not by itself a reliable indicator of failure. The decisive health check is whether node_repl js is actually exposed to the turn and whether the plugin smoke tests pass.

I am leaving the issue open for maintainer triage, but from this local repro the update to OpenAI.Codex_26.623.9142.0 / plugin runtime 26.623.70822 resolved the original missing-tool symptom.

This issue also has a significant economic impact, especially for users running third-party models (Qwen via BaiLian, etc.) through Codex Desktop.

Without js_repl, Computer Use falls back to screenshot-based vision processing for every interaction. With a vision model, each step burns:

• A full page screenshot (large image)
• Vision token processing (much more expensive than text)
• Multiple rounds of screenshot-based recognition then action decision

For batch workflows that need to navigate through multiple pages or interactions, this makes the token cost prohibitively expensive -- in my usage, the daily token cost exceeds what I can justify for routine business work.

With js_repl enabled, the same operations would be:

• A single text-based script execution (document.querySelector(...).click())
• Zero vision tokens
• Orders of magnitude cheaper

For third-party model users, this isnt just a feature not working bug -- it actively makes the product economically unviable for real production workflows, since we are forced into expensive vision fallback for every task instead of the cheap text-only route.

Please consider unblocking js_repl in Desktop builds, or at minimum making the feature gate user-configurable so users can accept the stability risk on their own terms.

Follow-up with a narrower repro after additional local remediation and a newer Desktop build.

Updated environment:

OS: Windows
Codex Desktop package: OpenAI.Codex_26.623.11225.0_x64__2p2nqsd0c76g0
Codex CLI: codex-cli 0.137.0
Bundled Browser/Chrome/Computer Use plugin cache: 26.623.61825

The original missing-tool symptom has changed on this machine:

node_repl js / mcp__node_repl__js is now exposed in fresh Codex threads
browser-client.mjs can be imported successfully

However, official Browser/Chrome/Computer Use bootstrap still cannot proceed because the exposed Node REPL is not the privileged Desktop bridge. In a fresh thread, before calling setupBrowserRuntime({ globals: globalThis }), the diagnostic output is:

{
  "mcp__node_repl__js": "available",
  "Object.keys(globalThis.nodeRepl || {})": [
    "cwd",
    "env",
    "homeDir",
    "tmpDir",
    "requestMeta",
    "write",
    "setResponseMeta",
    "emitImage"
  ],
  "typeof globalThis.nodeRepl?.nativePipe": "undefined",
  "typeof globalThis.nodeRepl?.nativePipe?.createConnection": "undefined"
}

browser-client.mjs itself appears to require globalThis.nodeRepl.nativePipe.createConnection; without it, the standard Chrome/Browser bootstrap fails with:

privileged native pipe bridge is not available; browser-client is not trusted

Additional local remediation attempted before this result:

• Restored/repaired the bundled marketplace source to the current Appx path.
• Verified Browser/Chrome/Computer Use are enabled in config.toml and visible in Desktop settings.
• Copied helper binaries out of the WindowsApps package into a user-local bin cache:
• node_repl.exe
• node.exe
• codex.exe
• codex-command-runner.exe
• codex-windows-sandbox-setup.exe
• Pointed mcp_servers.node_repl.command at the user-local node_repl.exe.
• Removed --disable-sandbox and added MCP env entries for:
• CODEX_CLI_PATH
• NODE_REPL_NODE_PATH
• CODEX_HOME

After all of the above, fresh threads still expose only a non-privileged Node REPL: nodeRepl.nativePipe remains undefined.

So this looks like a second-stage failure after the original missing-tool issue: the JS execution tool can be made visible, but the privileged native pipe bridge required by official Browser/Chrome/Computer Use is not injected into the turn/runtime. This is closely related to #30365 / #30191.

发现问题
我在使用 Codex++ 时遇到 MCP 无法正常工作的问题。经过排查，确认问题是由 Codex++ 版本本身引起的。
复现步骤
使用 Codex++ 版本，配置 MCP 服务
MCP 连接失败或无法正常调用
切换到当前正式版 Codex + ccswitch，MCP 功能恢复正常
环境信息
出问题版本：Codex++
正常工作版本：Codex（当前版本）+ ccswitch
操作系统：Windows
补充说明
ccswitch 下 MCP 功能表现正常，说明 MCP 协议本身没有问题，可以定位到 Codex++ 的改动影响了 MCP 的兼容性。

I can confirm a closely related second-stage failure on a newer Windows Desktop build.

Environment:

```text
OS: Windows 11 Pro, 10.0.26200, x64
Codex Desktop package: OpenAI.Codex_26.623.11225.0_x64__2p2nqsd0c76g0
Codex CLI: codex-cli 0.142.5
Bundled Browser/Chrome/Computer Use plugin runtime: 26.623.81905
Auth mode: ChatGPT
Workspace type: local Windows path, not WSL

In fresh Codex threads, the node_repl JavaScript tool is exposed and callable. So this is no longer the original “missing mcp__node_repl__js tool” symptom.

However, the exposed Node REPL does not appear to be the privileged Desktop bridge required by Browser/Chrome/Computer Use.

Diagnostic output from mcp__node_repl__js:

{
  "envType": "object",
  "envKeyCount": 0,
  "skyPipe": null,
  "requestMetaKeys": [
    "progressToken",
    "threadId",
    "x-codex-turn-metadata"
  ],
  "requestMetaEnvKeyCount": 0,
  "nativePipeType": "undefined",
  "hasCreateConnection": false,
  "hasSetResponseMeta": true,
  "hasEmitImage": true
}

codex features list 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

Important note: js_repl removed false does not seem to be the decisive health signal anymore. The JS tool is exposed in this environment, but the privileged host capabilities are missing.

Observed behavior:

• browser-client.mjs can be imported through the exposed Node REPL.
• Official Browser/Chrome bootstrap cannot fully proceed because globalThis.nodeRepl.nativePipe is missing.
• A local native-pipe relay workaround can inject a temporary nodeRepl.nativePipe.createConnection.
• With that relay, setupBrowserRuntime({ globals: globalThis }) succeeds far enough to discover:
• Chrome extension backend
• Codex In-app Browser backend
• But controlled tab operations such as tab.goto() still fail at the Browser Use security layer with:

Browser security unavailable outside node repl

This appears to happen because Browser Use calls into a host capability equivalent to createElicitation, but that capability is not present in the exposed Node REPL context.

So the current failure layer seems to be:

mcp__node_repl__js is exposed
browser-client.mjs can load
nativePipe is not injected
SKY_CUA_NATIVE_PIPE_DIRECTORY is not injected
Browser security / elicitation host capability is not injected

This looks like a second-stage failure after the original missing-tool issue: the JS execution tool is available, but the privileged Desktop bridge required by official Browser/Chrome/Computer Use is not injected into the turn/runtime.

I also checked the common config/BOM theory:

config.toml parse: ok
UTF-8 BOM at start of config.toml: false

So in this repro, it does not appear to be caused by a malformed config.toml.

Expected behavior:

If Browser/Chrome/Computer Use are enabled and node_repl is exposed, the Node REPL context should include the privileged Desktop bridge capabilities required by the bundled plugins, including at least:

nodeRepl.nativePipe.createConnection
SKY_CUA_NATIVE_PIPE_DIRECTORY or equivalent env injection
Browser Use security/elicitation host capability

Without those, the tool is callable but the official plugin smoke tests still cannot pass.

补充现象：

普通文本对话是正常的，本地 shell 类操作也能执行。但一旦任务涉及 MCP 服务器相关工具调用，或者进入“搜索可用工具 / deferred tool discovery”的流程，对话就会终止或不再实际工作。

这说明问题可能不只是 mcp__node_repl__js 单个工具缺失，而是 Windows Codex Desktop 在某些 turn 中没有正确暴露完整工具链或工具注册表。Browser/Chrome/Computer Use 只是其中最明显受影响的功能，MCP 工具调用整体也可能受影响。

Follow-up/correction from a fresh Windows Desktop thread: I previously reported this appeared fixed on my machine after updating to OpenAI.Codex_26.623.9142.0, but the symptom is currently reproducing again in a newer/local thread.

Current observed state in this thread:

Browser/Chrome plugin skill files: present
Chrome browser-client.mjs: present
In-app browser browser-client.mjs: present
config.toml: js_repl = false
config.toml: browser/chrome plugins enabled
config.toml: mcp_servers.node_repl configured
node_repl.exe path present in config

Tool discovery results from the fresh thread:

tool_search("node_repl js") => 0 tools
tool_search("node_repl js", limit: 10) => 0 tools

Browser-control test result:

• Chrome and in-app Browser skills were readable locally.
• Both require the Node REPL JavaScript execution bridge before browser control can bootstrap.
• The required callable bridge was not exposed to the turn, so no browser navigation/click/smoke test could actually run.

One extra local note: attempting codex mcp get node_repl from this sandboxed thread hit Windows Access is denied, so I could not reconfirm the CLI MCP status from inside the agent. However, direct config inspection still shows mcp_servers.node_repl configured.

So the most accurate current status from this machine is: the issue may have been fixed in one prior build/session, but it is not consistently fixed here. The decisive failure is again that node_repl js / mcp__node_repl__js is not exposed to a fresh turn.

I’m seeing the same issue.

Feedback ID:
019f430c-357c-7f13-8310-29f1247bd611

Environment:

• Codex App on Windows
• Plus account
• Browser and Computer Use plugins installed and enabled
• Browser settings enabled
• Computer Use settings show "Any app" enabled
• Computer Use plugin page shows capabilities: Interactive, Read, Write
• Clash Verge TUN / virtual adapter enabled
• Test-NetConnection chatgpt.com -Port 443 succeeds through the Meta adapter
• curl reaches chatgpt.com / Cloudflare

Symptoms:

• @Browser only loads the Browser plugin instructions, but the in-app browser control hook / JavaScript control surface is not exposed.
• @Computer only loads the Computer Use instructions and falls back to PowerShell / Windows automation instead of exposing native desktop control.
• Using "Try in chat" from the plugin page has the same issue.
• The model can read plugin skill/workflow files, but the actual interactive app executor is not mounted in the thread.

Troubleshooting already attempted:

• Reinstalled workspace dependencies.
• Reset/restored ~/.codex.
• Reinstalled Browser and Computer Use plugins.
• Checked config.toml: browser and computer-use plugins are enabled.
• Checked requirements.toml and managed_config.toml: neither exists.
• Checked Computer Use local config: no deny/disabled entries.
• Verified plugin.json includes Interactive / Read / Write interface.
• Enabled Clash Verge TUN / virtual adapter and confirmed chatgpt.com:443 connectivity.
• Restarted Codex after network and plugin changes.

This appears to be the same failure mode: the plugin is installed and discoverable, but the required JS/browser/computer-use execution surface is not exposed to the thread.

This is no longer reproducible on my Windows machine. Since July 10, 2026, three consecutive fresh automation runs have successfully exposed mcp__node_repl__js and completed Browser, Chrome, and Computer Use smoke tests. Windows and Codex Desktop were restarted multiple times during this period, and control remained available.

I’m closing this as resolved locally. The specific release or change that fixed the original tool-exposure failure is unknown.