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

Summary

On Windows Codex Desktop, the bundled Chrome/Browser/Computer Use plugins appear installed and enabled, and node_repl is registered as an MCP server, but the required JavaScript execution tool is not exposed to Codex turns.

Missing tool:

mcp__node_repl__js

This blocks both Chrome browser control and Computer Use before either can run its first smoke test.

This looks related to the same general failure family as #30249, #29251, #29482, #24727, and #24387, but the symptom in this case is that the node_repl/js tool is not exposed at all, rather than returning sandboxPolicy, sandboxCwd, or transport errors after invocation.

Environment

OS: Windows 11 Pro, 10.0.26200, x64
Codex Desktop package: OpenAI.Codex_26.623.5546.0_x64__2p2nqsd0c76g0
Codex CLI: 0.142.3
Bundled Chrome/Browser/Computer Use plugin runtime observed: 26.623.42026
Auth mode: ChatGPT
Workspace type: local Windows path, not WSL

Installed components verified

The bundled plugin files are present locally:

%USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome\26.623.42026\scripts\browser-client.mjs
%USERPROFILE%\.codex\plugins\cache\openai-bundled\browser\26.623.42026\scripts\browser-client.mjs
%USERPROFILE%\.codex\plugins\cache\openai-bundled\computer-use\26.623.42026\scripts\computer-use-client.mjs

The Chrome extension host is also observed running from the bundled Chrome plugin cache.

Feature registry state

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

MCP state

codex mcp get node_repl reports:

node_repl
  enabled: true
  transport: stdio
  command: %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\1b23c930bdf84ed6\bin\node_repl.exe
  args: -
  cwd: -
  startup_timeout_sec: 120

The environment includes browser/computer-use related variables such as:

BROWSER_USE_AVAILABLE_BACKENDS
BROWSER_USE_CODEX_APP_BUILD_FLAVOR
BROWSER_USE_CODEX_APP_VERSION
NODE_REPL_INSTRUCTIONS_USE_CASE_BROWSER
NODE_REPL_INSTRUCTIONS_USE_CASE_CHROME
SKY_CUA_NATIVE_PIPE
SKY_CUA_NATIVE_PIPE_DIRECTORY

Reproduction steps

Open Codex Desktop on Windows.
Ensure bundled Chrome, Browser, and Computer Use plugins are installed/enabled.
Start a fresh Codex thread.
Ask Codex to run a Chrome or Computer Use smoke test.
Per the plugin skill instructions, the assistant searches for the Node REPL JavaScript execution tool.

Discovery queries attempted:

node_repl js
mcp__node_repl__js
js
node_repl js JavaScript execution

Actual behavior

The mcp__node_repl__js tool is not exposed. Searches return either zero results or unrelated tools. As a result:

Chrome setup cannot import scripts/browser-client.mjs through the required JS execution route.
Computer Use cannot run the required first smoke test:

globalThis.apps = await sky.list_apps();
nodeRepl.write(JSON.stringify(apps, null, 2));

This blocks before any Chrome tab selection, page navigation, app listing, or Windows app control can occur.

Expected behavior

If Chrome/Browser/Computer Use are enabled and node_repl is registered, the Node REPL JavaScript execution tool should be exposed to the turn, typically as:

mcp__node_repl__js

Then the standard plugin bootstrap code should be able to run.

Troubleshooting already tried

Restarted Codex Desktop and Windows.
Created fresh Codex threads.
Rebuilt bundled plugin cache by renaming %USERPROFILE%\.codex\plugins\cache\openai-bundled and letting Codex recreate it.
Renamed/rebuilt Electron-style app/browser cache folders under:

%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Roaming\Codex\web\Codex

Verified node_repl.exe --help includes --disable-sandbox.
Tried adding --disable-sandbox via config and through the MCP Settings UI.
Confirmed Desktop rewrites/ignores the effective node_repl args; codex mcp get node_repl still reports args: -.
Checked Windows Defender: only sample-submission prompt was observed, not an actual block/quarantine event.
Ran codex doctor --ascii --all outside the sandbox. WebSocket and provider reachability were OK, MCP config loaded, auth configured.
Attempted the known workaround of reopening Codex Desktop as Administrator, but the running thread/worker still reported IsAdmin=False and the tool was still not exposed.

Additional diagnostic output

codex doctor --ascii --all reports the main installation/config/connectivity checks as OK, including:

config       loaded
auth         auth is configured
mcp          1 server (1 stdio) · 0 disabled
websocket    connected
reachability active provider endpoints are reachable over HTTP

The only remaining diagnostic failure is TERM=dumb, which appears unrelated to MCP tool exposure.

Notes

This may be related to the Desktop config/tool registry behavior described in #24387, where Desktop startup rewrites features.js_repl and mcp_servers.node_repl. In this case the key blocker is that the high-level plugin surfaces are enabled, but the underlying JS execution bridge required by the plugin skills is not callable from the thread.

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

Browser / Chrome / Computer Use plugins enabled but unusable: node_repl JS tool not exposed #30026
[Windows Desktop] Browser Use unavailable: js_repl removed but browser_use still enabled #29229
Codex Desktop Computer Use plugin visible but runtime tools are not injected #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:

Basic Node bridge:

node-repl-smoke-ok

Computer Use:

globalThis.apps = await sky.list_apps();

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

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.

@computer

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.

Navigation Menu

Repository navigation

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

Summary

Environment

Installed components verified

Feature registry state

MCP state

Reproduction steps

Actual behavior

Expected behavior

Troubleshooting already tried

Additional diagnostic output

Notes

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Summary

Environment

Installed components verified

Feature registry state

MCP state

Reproduction steps

Actual behavior

Expected behavior

Troubleshooting already tried

Additional diagnostic output

Notes

Activity

github-actions commented on Jun 28, 2026

victurbo37-debug commented on Jun 28, 2026

2agathon commented on Jun 29, 2026

victurbo37-debug commented on Jun 30, 2026

shqpyy commented on Jun 30, 2026

2agathon commented on Jul 1, 2026

dasdsadwqf commented on Jul 2, 2026

windchasersky commented on Jul 2, 2026

wxt888qwerty commented on Jul 3, 2026

victurbo37-debug commented on Jul 5, 2026

Pzgnb commented on Jul 8, 2026

victurbo37-debug commented on Jul 12, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions