›_ Codex Issues
Codex Issues / #27566

I am seeing what looks like the same Windows bundled runtime relocation failure on Codex Desktop.

Open 💬 5 comments Opened Jun 11, 2026 by sunquan1024
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

版本 26.608.12217 • 发布于 2026年6月9日

What subscription do you have?

plus

What platform is your computer?

_No response_

What issue are you seeing?

I am seeing what looks like the same Windows bundled runtime relocation failure on Codex Desktop.

Environment:

  • OS: Windows
  • Codex Desktop: 26.608.1337.0
  • Install path: C:\Program Files\WindowsApps\OpenAI.Codex_26.608.1337.0_x64__2p2nqsd0c76g0
  • Plugin: computer-use@openai-bundled enabled
  • Computer Use plugin files exist, including:
  • scripts/computer-use-client.mjs
  • node_modules/@oai/sky/bin/windows/codex-computer-use.exe

Symptom:

  • Computer Use is listed/enabled, but no Node REPL JavaScript tool is exposed in the session.
  • mcp__node_repl__js, js, and js_reset are not available.
  • As a result, Computer Use cannot bootstrap through the official computer-use-client.mjs path.

Relevant log lines:

warning bundled_executable_relocation_failed
destinationPath=C:\Users\<user>\AppData\Local\OpenAI\Codex\runtimes\cua_node\.staging-...
errorCode=EIO
errorMessage="Bundled executable relocation failed during copy_directory"
executableName=node.exe
failedExecutableName=node.exe
sourceKind=windowsapps
sourcePath="C:\Program Files\WindowsApps\OpenAI.Codex_26.608.1337.0_x64__2p2nqsd0c76g0\app\resources\cua_node"
warning bundled_executable_relocation_failed
executableName=node_repl.exe
failedExecutableName=node_repl.exe
errorCode=EIO
operation=copy_directory
Then:
warning [computer-use-native-pipe] computer-use native pipe startup failed
errorMessage="Windows Computer Use helper paths are unavailable"
And:
info [BrowserUseThreadConfig] browser_use_setup_failed backend=node_repl phase=runtime-paths platform=win32 reason=node-repl-missing
Things checked:
Source files exist under ...\app\resources\cua_node\bin\, including node.exe and node_repl.exe.
cipher /c reports the files are not encrypted.
Manually copying the runtime from the WindowsApps source into C:\Users\<user>\AppData\Local\OpenAI\Codex\runtimes\cua_node succeeds.
Manually running Node's fs.cp(src, dst, { recursive: true }) against the same source and a staging destination succeeds.
Even after the local cache contains bin/node.exe, bin/node_repl.exe, bin/node_modules, and manifest.json, Codex Desktop still tries to relocate into a fresh .staging-* path on startup and fails before exposing Node REPL tools.
Question:
Is there a known workaround for this WindowsApps runtime relocation failure, or a way to force Codex Desktop to use an already-populated local cua_node runtime cache?

### What steps can reproduce the bug?

null

### What is the expected behavior?

_No response_

### Additional information

_No response_

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 2 months ago

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

  • #26661

Powered by Codex Action

wugang019-art · 2 months ago

Windows 原生工作区仍可复现。

  • Computer Use 插件版本：26.609.30741
  • computer-use@openai-bundled 已启用
  • 插件文件 scripts/computer-use-client.mjs 存在
  • 但当前会话未注入 mcp__node_repl__js、js 或 js_reset
  • 因此无法通过官方 computer-use-client.mjs 路径启动 Computer Use
  • 已尝试完整重启 Codex、重新启用插件并新建会话，问题依旧

当前会话的工具清单已直接验证缺少上述 Node REPL JavaScript 执行工具。请协助检查 Computer Use 插件工具注册、app-server 运行时路径解析以及会话工具注入流程。

asei-proxima · 2 months ago

I can reproduce a very similar issue on Codex Desktop 26.611.8273.0.

Environment:

  • Windows / Microsoft Store Codex Desktop
  • Codex package: OpenAI.Codex_26.611.8273.0_x64__2p2nqsd0c76g0
  • User profile path contains Japanese characters: C:\Users\<JapaneseUser>\...
  • Computer Use plugin: openai-bundled/computer-use/26.609.41114

Symptoms:

  • Computer Use bootstrap fails with:

Module not found: @oai/sky/dist/project/cua/sky_js/src/targets/windows/internal/computer_use_client_base.js

  • nodeRepl.config is absent
  • nodeRepl.nativePipe is absent
  • no SKY/CUA env vars are present

Desktop logs show:

  • bundled_executable_relocation_failed
  • errorCode=EIO
  • errorMessage="Bundled executable relocation failed during copy_directory"
  • sourcePath="C:\Program Files\WindowsApps\OpenAI.Codex_26.611.8273.0_x64__2p2nqsd0c76g0\app\resources\cua_node"
  • then:

[computer-use-native-pipe] computer-use native pipe helper paths unavailable
missingHelperPath=true missingTransportModulePath=true platform=win32

Things tried:

  • Fully restarted Codex Desktop
  • Updated from 26.609.x to 26.611.8273.0
  • Manually copied cua_node from WindowsApps to %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node
  • Verified the expected @oai/sky file exists in the copied runtime
  • Manual robocopy and Node fs.cp from the same WindowsApps source to an AppData probe directory succeed

Despite that, Codex Desktop still attempts its own relocation into a fresh .staging-* directory and fails with EIO before Computer Use/native pipe becomes available.

This looks like the same Windows bundled runtime relocation / non-ASCII path handling class of bug, still reproducible on 26.611.8273.0.

2agathon · 1 month ago

I turned a related Windows field case into a small public diagnostic lab:

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

The part most relevant to this issue is the runtime-relocation evidence model and the read-only Doctor script. It checks the packaged cua_node source, the relocated runtime, node.exe / node_repl.exe, plugin clients, Native Messaging, and recent relocation/native-pipe log signatures without rewriting Codex caches.

One useful conclusion from the case: “plugin installed/enabled”, “runtime relocated”, “mcp__node_repl__js injected”, and “privileged native pipe available” are separate gates. Treating them as one state led to a lot of false fixes.

This is an independent community experiment, not an official repair or a claim that every report has the same root cause. The evidence in the repo is redacted and marked by provenance.

zemeng5208 · 16 days ago

I maintain WinBridge Recovery, an independent recovery/diagnostic tool for Windows Codex Desktop local plugin/runtime state: https://github.com/zemeng5208/winbridge-recovery

This report is a particularly useful match because the relocation failure is EIO, while direct robocopy / Node fs.cp from the same packaged cua_node source can succeed. That suggests the source payload itself is readable and the failure can be specific to Desktop's staging/materialization lifecycle rather than a universally unreadable package.

WinBridge v3.1.1 resolves the currently installed Store AppX, reads the bundled CUA manifest, verifies the official runtime/plugin resources, and creates a user-owned verified mirror using byte-stream copying plus source/destination SHA-256 checks. It then validates the node_repl command, NODE_REPL_NODE_PATH, CODEX_CLI_PATH, CUA runtime paths, marketplace/cache versions and related helper state before doing an atomic staged switch with rollback data.

So the variant in this thread where the official files are present/readable but Codex repeatedly ignores a complete user-side runtime and fails a fresh .staging-* relocation is within the local recovery layer WinBridge is intended to diagnose and potentially recover.

One limitation is important: a complete local cua_node runtime does not by itself guarantee that Desktop will expose mcp__node_repl__js to the active thread. If the runtime, config and helper paths are all healthy but tool injection is still absent, WinBridge should report that as an upstream Desktop/tool-provisioning failure rather than force a workaround.

The project does not take ownership of, decrypt, patch, or change ACLs on WindowsApps.