Skip to content

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

Open
Open
Computer Use permanently unavailable on Windows (CLI 0.142.4 + Desktop 26.623): nativePipe never injected despite healthy helper#30685
Labels
CLIIssues related to the Codex CLIappIssues related to the Codex desktop appbugSomething isn't workingcomputer-usewindows-osIssues related to Codex on Windows systems

Description

@970074027-sudo
970074027-sudo
opened on Jun 30, 2026

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): 
    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.

Activity

  1. github-actions
    added
    bugSomething isn't working
    CLIIssues related to the Codex CLI
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    computer-use
    on Jun 30, 2026

  2. github-actions commented on Jun 30, 2026

    @github-actions
    github-actionsBot
    on Jun 30, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. yundongbanxia commented on Jul 2, 2026

    @yundongbanxia
    yundongbanxia
    on Jul 2, 2026 – with ChatGPT Codex Connector

    I have a related data point that suggests this is not necessarily an unrecoverable host-side regression.

    On my affected Windows Store/MSIX install, bundled plugin resources under C:\Program Files\WindowsApps\OpenAI.Codex_...\app\resources\... were marked as EFS / Application Protected. Normal copy relocation failed, which prevented bundled plugins from being recognized and prevented node_repl from being injected.

    After reinstalling Codex so the package landed on the system drive and the same bundled source files showed U instead of E in cipher /c, Computer Use and the in-app Browser recovered and stayed stable across restarts.

    I left the fuller A/B details and upstream fix suggestion in #25220.

  4. 2agathon commented on Jul 13, 2026

    @2agathon
    2agathon
    on Jul 13, 2026 – with ChatGPT Codex Connector

    A related Windows case produced a reusable diagnostic lab that may help separate “helper exists” from “privileged pipe is actually injected”:

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

    The support matrix treats these as independent gates: helper/runtime files, callable mcp__node_repl__js, nodeRepl.nativePipe, and the final Browser/Chrome/Computer Use action. The included Doctor is read-only and surfaces relocation/native-pipe log signatures; the acceptance prompts explicitly forbid fallback tools so a shell/UI workaround cannot be mistaken for official Computer Use.

    This adds a protocol and evidence model rather than another one-off cache patch. It is an independent community experiment, not an official workaround, and it does not assume EFS is the root cause for every report.

  5. surqi commented on Sep 28, 2026

    @surqi
    surqi
    on Sep 28, 2026

    I can reproduce this on Codex Desktop 26.924.2738.0, Windows 11 build 26200.

    The helper process is running and the configured codex-computer-use named pipe exists, but nodeRepl.nativePipe is absent. codex doctor reports:

    node_repl env var CODEX_WINDOWS_REGISTERED_CORE is not set

    Confirmed that coreGateEnabledAtStartup=false, selectedRuntimeSource=bundled, and appPackageCoreActive=false. Even with sandbox_mode = 'workspace-write', the setup wizard is gated off and no UAC prompt is triggered.
    The issue persists after fully rebuilding cua_node, node_repl state, and the generated MCP configuration.

    Feedback ID: 01a0e873-4f88-73b1-81d7-bc4c66dfa97b

  6. Yue-wei-Wang commented on Oct 8, 2026

    @Yue-wei-Wang
    Yue-wei-Wang
    on Oct 8, 2026 – with ChatGPT Codex Connector

    Additional Windows reproduction (2026-10-08): native Computer Use pipe exists, but the session's Sky runtime is not injected

    I can reproduce Windows Computer Use Sky runtime is unavailable on a separate Windows installation, including a fresh Codex conversation. This case is noteworthy because the native Computer Use pipe and helper process do exist; the failure happens before any desktop operation can run.

    Environment

    • Windows, Microsoft Store/MSIX package: OpenAI.Codex 26.1002.7124.0 (verified with Get-AppxPackage).
    • codex doctor --summary: 21 ok, 1 idle, 3 notes, 2 warnings, 0 fail (degraded).
    • codex doctor includes: node_repl: env var CODEX_WINDOWS_REGISTERED_CORE is not set (correlation only, not confirmed as the root cause).

    Read-only observations

    1. PowerShell enumeration of \\.\pipe\ finds an active codex-computer-use-<UUID> named pipe (UUID omitted).
    2. Get-Process shows codex-computer-use-swift running and three node_repl processes.
    3. In a fresh Codex Computer Use diagnostic, the official mcp__node_repl__js tool is callable and successfully evaluates JS, but:
      • globalThis.nodeRepl?.config is undefined;
      • globalThis.nodeRepl?.nativePipe is undefined;
      • SKY_CUA_NATIVE_PIPE_DIRECTORY is absent from nodeRepl.env.
    4. Attempting the official Computer Use client bootstrap fails during the client module-load/runtime-location stage with the exact error: 
      Windows Computer Use Sky runtime is unavailable
      The attempted sky.list_apps() was not executed.
    5. config.toml contains both [mcp_servers.node_repl] and [mcp_servers.node_repl.env] sections (contents not altered). The registry path HKLM\SOFTWARE\OpenAI\Codex\WindowsSandboxService\RegisteredCore is absent, and the user does not see a Windows setup/retry banner; neither observation establishes root cause.
    6. A read-only search of ~/.codex/.sandbox/sandbox*.log for os error 32, setup refresh had errors, and runtime read/execute validation failed produced no matching lines. This does not rule out missing or differently located logs.

    Assessment / maintainer question

    This differs from reports in which no Computer Use pipe or helper ever starts. Here the native pipe and codex-computer-use-swift are present, and generic JS execution works, but the Computer Use-specific runtime context/bridge is absent in the REPL session. Could maintainers confirm the supported initialization/injection path on current Windows builds and whether there is a supported diagnostic or repair for this mismatch?

    No registry, sandbox, runtime, or plugin configuration was modified in these tests. Paths, usernames, pipe UUID, and other identifying local details are intentionally omitted.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    CLIIssues related to the Codex CLIappIssues related to the Codex desktop appbugSomething isn't workingcomputer-usewindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions