Browser / Chrome / Computer Use plugins enabled but unusable: node_repl JS tool not exposed

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

• #28481
• #29921
• #29373
• #28757

Powered by Codex Action

I am seeing the same issue on Windows Codex Desktop.

Feedback ID: 019f0240-11b0-7922-b18a-a99d61013412

Summary:
Computer Use plugin is installed and enabled, but the privileged Computer Use node_repl/nativePipe runtime is not injected into agent sessions.

Manual node_repl MCP can expose node_repl/js, but it is not privileged:

{
"hasNodeRepl": true,
"hasConfig": false,
"hasNativePipe": false,
"nodeReplEnvKeys": [],
"nodeReplNodeModuleDirs": null,
"skyNativePipeDirectory": null
}

computer-use-client.mjs fails with:
Windows Computer Use Sky runtime is unavailable

Codex Desktop: OpenAI.Codex 26.616.10790.0
Computer Use plugin: 26.616.51431
Windows sandbox is set to unelevated.

Codex Desktop on Windows: Chrome plugin present but node_repl js missing after restart

This is a sanitized field report from a Windows Codex Desktop debugging session. It may help other users who see Chrome / Browser / Computer Use plugins installed, but mcp__node_repl__js or node_repl js is not exposed after restarting Codex Desktop or Chrome.

Environment

• OS: Windows 10
• Codex Desktop: 26.623.x
• Chrome: normal installed Chrome, main user profile, launched as chrome.exe --profile-directory="Default"
• Codex home actually used by the running session: a custom CODEX_HOME, not %USERPROFILE%\.codex
• Chrome extension id: hehggadaopoacecdllhhajmbjkdcmajg
• Native host name: com.openai.codexextension

Symptoms

• chrome:control-chrome and browser:control-in-app-browser skills existed.
• Chrome extension was installed and enabled in the main Chrome profile.
• Native messaging manifest existed and looked valid.
• The Chrome extension host process could run.
• However, after restarting Codex Desktop, tool discovery for:
• node_repl js
• mcp__node_repl__js
• Chrome control tools

returned no usable JavaScript execution tool.

In one intermediate state, node_repl.exe was running, but the js tool still was not registered in the active model session.

Root Causes Found

There were two overlapping problems.

1. Split Codex home

The running Codex session had:

CODEX_HOME=<custom drive>\CodexHome

but earlier repair attempts had mostly updated:

%USERPROFILE%\.codex

As a result, changes appeared to work in one session or one path, but did not survive restart because the active Codex Desktop process was reading the other config.toml and plugin cache.

The active CODEX_HOME\config.toml also did not contain the expected mcp_servers.node_repl block.

2. Bundled runtime relocation failed because WindowsApps files had encrypted attributes

Codex Desktop 26.623 expected a newer local runtime:

cua_node 0.0.2 / node_repl 20260619.1

but the local runtime cache still contained an older one:

cua_node 0.0.1 / node_repl 20260609.1

Codex logs showed errors like:

bundled_executable_relocation_failed
operation=copy_directory
originalError code=UNKNOWN syscall=copyfile

Manual copy attempts from the WindowsApps package also failed with:

The specified file could not be encrypted.

The current Codex package resources under C:\Program Files\WindowsApps\... had the Windows Encrypted file attribute. Normal copy operations tried to preserve or trigger that attribute and failed, so the new runtime never landed in %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node.

Fix That Worked

A. Confirm the active Codex home

Inside the active Codex session, check:

Get-ChildItem Env:CODEX*

Do not assume %USERPROFILE%\.codex is the active config directory.

Important note: in the successful final state, Codex Desktop rewrote features.js_repl back to false, but mcp__node_repl__js was still exposed and worked. In this case, features.js_repl = false alone was not a reliable signal of failure. The better health check was whether tool discovery could actually find node_repl js, and whether node_repl.exe was running from the expected current runtime directory.

B. Repair the active Codex home, not the inactive one

Run the bundled/plugin repair against the actual CODEX_HOME.

The active config.toml should include the Chrome / Browser / Computer Use plugin entries, and the active chrome-native-hosts.json / chrome-native-hosts-v2.json should point at current plugin paths.

C. Use sandbox = "unelevated" on Windows

In the active CODEX_HOME\config.toml:

[windows]
sandbox = "unelevated"

This matched a known workaround reported by other Windows users where sandbox = "elevated" prevented node_repl / Browser Runtime from becoming usable.

D. Manually copy the new runtime without preserving encrypted attributes

Normal Copy-Item, robocopy, and cmd copy failed because of encrypted WindowsApps source files.

The working approach was to copy files by reading bytes and writing new files, which did not preserve the encrypted attribute.

Conceptually:

$bytes = [System.IO.File]::ReadAllBytes($source)
[System.IO.File]::WriteAllBytes($destination, $bytes)

This was used to copy:

<Codex WindowsApps>\app\resources\cua_node

to a new local runtime directory under:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<new-runtime-id>

and the current Codex helper binaries to:

%LOCALAPPDATA%\OpenAI\Codex\bin\<new-bin-id>

After copying, verify:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<new-runtime-id>\bin\node_repl.exe --help
%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<new-runtime-id>\bin\node.exe --version
%LOCALAPPDATA%\OpenAI\Codex\bin\<new-bin-id>\codex.exe --version

E. Update stale runtime pointers

Update these files in the active Codex home and local Codex state so they no longer point to older app/runtime versions:

CODEX_HOME\chrome-native-hosts.json
CODEX_HOME\chrome-native-hosts-v2.json
%LOCALAPPDATA%\OpenAI\Codex\chrome-native-hosts-v2.json

The stale entries pointed to older versions such as:

OpenAI.Codex_26.616...
cua_node\<old-runtime-id>

They were updated to the current app version and the manually copied runtime:

OpenAI.Codex_26.623...
cua_node\<new-runtime-id>

The active config.toml also needed a matching mcp_servers.node_repl block pointing at the new local node_repl.exe, node.exe, and node_modules.

Validation That Confirmed the Fix

After restarting Codex Desktop:

• Tool discovery for node_repl js returned mcp__node_repl__js.
• node_repl.exe was running from the new local runtime path.
• Browser runtime setup succeeded.
• agent.browsers.get("extension") succeeded.
• browser.user.openTabs() returned already-open tabs from the real Chrome main profile.
• An existing Chrome tab was successfully claimed via browser.user.claimTab(...).

After restarting Chrome as well:

• Chrome relaunched as chrome.exe --profile-directory="Default".
• The native host relaunched from the active CODEX_HOME plugin cache.
• Codex could still list and claim an existing tab in the main Chrome profile.

This confirmed the fix survived both Codex Desktop restart and Chrome restart, and did not rely on a clean browser, temporary profile, or alternate Chrome account.

Final Classification

In this case the failure was not caused by:

• Chrome extension missing
• Chrome extension disabled in the main profile
• Native host manifest missing
• Main Chrome profile blocking all access
• Codex only being able to control a new profile

The actual failure was:

• active CODEX_HOME mismatch / split configuration
• stale 26.616 runtime pointers
• failed WindowsApps-to-local runtime relocation caused by encrypted WindowsApps package files
• old cua_node/node_repl runtime still being used after Codex Desktop updated

Suggested Product Fix

Codex Desktop on Windows could make this easier by:

• clearly showing the active CODEX_HOME in diagnostics
• detecting when config.toml, chrome-native-hosts.json, and local runtime cache disagree
• surfacing node_repl startup/registration failures in the UI
• handling WindowsApps encrypted file attributes during bundled runtime relocation
• automatically invalidating stale chrome-native-hosts-v2.json entries after app updates

I can reproduce this on the same Windows machine with a useful version boundary.

Version boundary on the same machine

• Working thread: 019f3aa1-dca9-7b73-bfb4-b5e547dbd002
• Working date: 2026-07-07
• Working Computer Use plugin: 26.623.101652
• The rollout contains real mcp__node_repl/js function calls that successfully ran setupComputerUseRuntime(...) and sky.list_apps().

The failure started after the 26.707 update:

• Broken Computer Use plugin: 26.707.31428 on 2026-07-12
• Still broken after reinstall: 26.707.61608 on 2026-07-13
• Current Codex Desktop package: 26.707.8168.0
• Broken thread: 019f59a0-cd7a-7073-83e0-1b3465cadbdf

Current state

• codex mcp list reports node_repl as enabled.
• The configured node_repl.exe, node.exe, and codex-computer-use.exe all exist.
• Multiple node_repl.exe processes are running as children of the Codex Desktop process.
• codex features list reports computer_use as stable true.
• Despite that, the active task's callable tool list contains no mcp__node_repl__js (and no usable discovery tool that can expose it), so the plugin cannot bootstrap.
• Reinstalling the bundled Computer Use plugin and restarting Codex did not restore the tool.

js_repl = false is not causal here

Local rollout history shows js_repl = false was already present by 2026-06-24, but Computer Use still worked on 2026-07-07 with plugin 26.623.101652.

The current CLI also reports:

computer_use  stable   true
js_repl       removed  false

I removed the stale js_repl config entry and revalidated the config; this did not change tool exposure.

This looks like a regression in task-level MCP tool injection/discovery between the 26.623 and 26.707 desktop/plugin builds, rather than a missing executable, stale runtime pointer, or the removed js_repl feature flag.

Codex /feedback reference (submitted without logs): 019f5a67-48f5-7560-b95e-f28e4a64c5fe.

Still reproducing on a newer Windows Codex Desktop build.

Environment

• Codex Windows app: 26.707.8168.0
• Windows 11 Pro, x64: 10.0.26200
• Browser plugin: 26.707.61608
• Computer Use plugin: 26.707.61608
• Bundled workspace runtime: 26.709.11516

Current behavior

• The in-app browser tab is open and its URL is supplied to the task as ambient browser context.
• The Browser and Computer Use skills are installed and readable.
• Their bundled client scripts are present.
• The required mcp__node_repl__js execution tool is not exposed in the task's tool registry.
• Consequently, neither the in-app browser runtime nor Computer Use can initialize.
• Reloading the tab, fully quitting/restarting Codex, and retrying in a new task did not help.

This confirms that the issue still exists on the newer 26.707 app/plugin generation. The original report for this reproduction was closed as a duplicate: #32720. No website contents, authentication data, or private browser data are included.

I published a reproducible diagnostic/acceptance lab for this exact symptom class:

https://github.com/2agathon/codex-control-runtime

Its main purpose is to distinguish four states that the UI currently makes easy to conflate:

1. plugin/skill files are present;
2. the relocated Node runtime is healthy;
3. mcp__node_repl__js is actually exposed to the task;
4. the privileged browser/computer-use bridge is injected.

The repo includes a read-only Windows Doctor plus three strict, no-fallback acceptance prompts for Browser, Chrome, and Computer Use. A task must report the real tool/runtime chain; it cannot silently substitute Playwright, Chrome DevTools MCP, shell automation, screenshots, or another browser MCP.

This is an independent community lab, not an official fix. It may be useful for producing comparable evidence across app/plugin updates without repeating cache surgery.