Computer Use permanently unavailable on Windows (CLI 0.142.4 + Desktop 26.623): nativePipe never injected despite healthy helper

What issue are you seeing?

Computer Use is permanently unavailable on Windows in both Codex CLI (0.142.4) and the Codex Desktop app (OpenAI.Codex 26.623.9142.0, MSIX). The plugin reports installed, enabled, but every call fails with:

Windows Computer Use Sky runtime is unavailable

Deeper probing inside the node_repl VM shows the privileged surface is never injected:

nodeRepl.nativePipe      = undefined
nodeRepl.config          = undefined
nodeRepl.createElicitation = undefined
nodeRepl keys            = cwd,env,homeDir,tmpDir,requestMeta,write,setResponseMeta,emitImage

Process/pipe monitoring during a live codex exec session confirms the helper is never spawned and no native pipe is ever created:

procs = [codex, node_repl]     # codex-computer-use.exe NEVER appears
pipes = []                      # \.\pipe\codex-computer-use-* NEVER created (entire 60s session)

This matches the symptom cluster in #25507 / #26528 / #25571, but my diagnosis below adds evidence that I believe narrows the root cause further than what's currently in those threads.

What steps can reproduce the bug?

1. Windows 11 Pro, build 10.0.26200.8655 (zh-CN). Codex CLI 0.142.4 at ~\AppData\Local\OpenAI\Codex\bin; Codex Desktop MSIX 26.623.9142.0 at C:\Program Files\WindowsApps\OpenAI.Codex_.... Both ship the identical codex.exe binary (same MD5).
2. codex plugin list reports computer-use@openai-bundled installed, enabled 26.623.70822.
3. codex exec "Use ONLY the computer-use plugin. Call sky.list_apps()..." → model reports no callable sky namespace / sky is not defined.
4. Manual repro inside the node_repl VM (node_repl.exe + js tool loading computer-use-client.mjs):

``js
await import(".../computer-use/scripts/computer-use-client.mjs")
await setupComputerUseRuntime({})
// → throws "Computer Use native pipe path is unavailable"
// at getComputerUsePipePath (computer-use-client.mjs:212)
// because getComputerUsePrivilegedNodeRepl().env.SKY_CUA_NATIVE_PIPE_DIRECTORY is undefined
// because nodeRepl.nativePipe is undefined
``

What is the expected behavior?

sky.list_apps() returns the list of targetable windows, i.e. the codex-computer-use.exe helper is spawned and the native pipe bridge is injected into node_repl, so the plugin's NativePipeComputerUseTransport can connect.

Additional information — diagnosis that narrows the root cause

I went deep on this and believe the evidence points to the codex.exe Rust backend in this build not implementing the native-pipe injection, rather than (only) the EFS/marketplace issues tracked elsewhere. Key findings:

1. The helper binary itself is fully functional. Spawning codex-computer-use.exe directly (outside the VM, via node.exe loading Sky's WindowsComputerUseClient) succeeds and returns 40 targetable apps:

SUCCESS! list_apps returned 40 apps:
  - Chrome.TYTYP5... (Google Chrome) [running]
  - electron.app.ZCode (ZCode) [running]
  - process:C:\Windows\explorer.exe (explorer) [running]
  ...

So the helper, the system UI-automation stack, permissions, and registry are all healthy. The problem is upstream of the helper.

2. The two transport paths and why both are dead for the plugin.

• The plugin uses NativePipeComputerUseTransport (computer-use-client.mjs:42), which requires globalThis.nodeRepl.nativePipe. This object is undefined because the codex host process never injects it.
• Sky's alternate WindowsHelperTransport (computer_use_client.js) spawns the helper directly via node:child_process. But this path is unusable from inside the node_repl VM: (a) it imports node:process, which is in the VM denylist (kernel.js:215 → deniedBuiltinModules = new Set(["process","node:process"])); and (b) even though node:child_process is not denied and imports fine, every spawn/spawnSync returns EPERM — the VM sandbox blocks process creation at the execution layer:

``
spawnSync("cmd",["/c","echo hi"]) → status=null, error EPERM
spawnSync("<cua_node>/node.exe",…) → EPERM
spawnSync("where",["cmd"]) → EPERM
`
globalThis.process is also undefined` inside the VM. So the plugin is architecturally forced onto the native-pipe path, and that path is never wired up.

3. No native-pipe/computer-use backend code runs in the host at all. Searching the run logs (logs_2.sqlite) for any target containing sky, computer_use, or cua returns zero log modules — i.e. the codex host never even attempts to start the computer-use pipe. A strings scan of codex.exe finds no codex-computer-use, SKY_CUA, or nativePipe symbols. This strongly suggests the host-side pipe-bridge bootstrap is absent or gated off in this build.

4. EFS encryption is real on this machine but is not the proximate cause. Per #25220, the MSIX app-bundle source files are EFS-encrypted:

C:\Program Files\WindowsApps\OpenAI.Codex_...\app\resources\plugins\openai-bundled\.agents\plugins\marketplace.json
  Attributes: Archive, Encrypted
Node fs.copyFileSync(src, dest) → FAIL (code: UNKNOWN)   # reproduces #25220
robocopy src dest              → OK (1435 bytes)          # bypasses EFS

I decrypted the user-local marketplace/plugin trees (cipher /D, ~1400 files), robocopy-refreshed them from the app bundle, removed + re-added the openai-bundled marketplace, and plugin remove+add'd computer-use. After this the plugin files are all unencrypted and installed, enabled — but codex-computer-use.exe is still never spawned and the pipe is still never created. So resolving the EFS/copy layer did not fix the native-pipe injection.

5. Feature flags are on; version is latest. codex features list shows computer_use = stable/true, tool_call_mcp_elicitation = stable/true, browser_use = stable/true. Browser Use works in the same install (it uses the separate native-messaging-host path via extension-host.exe, independent of nodeRepl.nativePipe), which is consistent with the pipe-injection layer being the isolated failure. CLI is 0.142.4 (= latest, no newer release to upgrade to).

Environment:

• OS: Windows 11 Pro, 10.0.26200.8655, zh-CN
• Codex CLI: codex-cli 0.142.4 (latest)
• Codex Desktop: OpenAI.Codex 26.623.9142.0_x64__2p2nqsd0c76g0 (MSIX)
• cua_node runtime: a89897d3d9baa117, @oai/sky 0.4.13
• computer-use plugin: 26.623.70822
• Subscription: ChatGPT (auth mode: chatgpt)

Related: #25507, #26528, #25571, #25391, #25665, #25220. Happy to run any further diagnostics the team suggests.