[Windows] Computer Use `list_apps` / `list_windows` fail with `spawn EPERM` in `@oai/sky` helper transport

Summary

On Codex Desktop for Windows, the bundled Computer Use skill and node_repl tool are both available, but the two lowest-risk discovery calls fail before the native helper can start:

sky.list_apps()    -> Error: spawn EPERM
sky.list_windows() -> Error: spawn EPERM

This is distinct from the more commonly reported native pipe unavailable, missing-helper-path, missing plugin cache, or missing tool-host failures. Browser/Chrome works in the same installation.

Environment

• Windows 11 x64, Windows-native Codex task (not WSL)
• Codex Desktop MSIX: 26.803.5235.0
• Bundled Computer Use plugin: 26.803.41515
• Codex CLI / Doctor: 0.147.0
• @oai/sky: 0.6.2
• PowerShell: 7.6.4, Core, x64
• Windows sandbox setting: unelevated

Minimal reproduction

1. Start a fresh projectless task in Codex Desktop for Windows.
2. Read the bundled Computer Use skill guidance and confirmations.
3. Initialize the bundled package through the documented node_repl path:

``js
const { sky } = await import("@oai/sky");
``

1. Call only the read-only discovery APIs:

``js
await sky.list_apps();
await sky.list_windows();
``

Both calls fail immediately. No app/window content, screenshots, activation, or input actions are involved.

Exact error

Both calls return:

Error: spawn EPERM
    at ChildProcess.spawn (node:internal/child_process:421:11)
    at spawn (node:child_process:796:9)
    at <WindowsHelperTransport> (<CODEX_RUNTIME>\bin\node_modules\@oai\sky\dist\project\cua\sky_js\src\targets\windows\internal\helper_transport.js:1:4423)

Error properties:

code=EPERM
errno=-4048
syscall=spawn

The failure occurs before the helper protocol or Windows UI discovery returns any data.

Local validation

• The expected codex-computer-use.exe exists in the active @oai/sky package.
• Its Authenticode signature is valid and signed by OpenAI OpCo, LLC.
• File ACLs include read/execute for the relevant sandbox user group; there is no Mark-of-the-Web alternate stream.
• The Computer Use helper, node_repl.exe, and @oai/sky package in the active runtime are byte-identical to the copies embedded in the installed MSIX.
• The plugin cache and manifests are present and complete.
• The generated node_repl environment includes SKY_CUA_NATIVE_PIPE and SKY_CUA_NATIVE_PIPE_DIRECTORY (values omitted).
• @oai/sky 0.6.2 does not reference either environment variable in its JS package. Its Windows transport unconditionally calls Node child_process.spawn() for the helper.
• sky.documentation is not exported by @oai/sky 0.6.2, although static plugin docs are present. Reading those static docs resolves the documentation mismatch but does not affect this transport failure.
• Recent Code Integrity, AppLocker, and Defender event checks contained no matching block event for the helper or node_repl.
• Browser/Chrome discovery works in the same Codex installation, so this is isolated to Computer Use helper startup.

Repair attempts that did not change the result

• Reinstalled the bundled Browser, Chrome, and Computer Use plugins one at a time through the supported plugin path.
• Restarted Codex and reproduced from fresh tasks.
• Confirmed the MSIX-bundled runtime and installed active runtime are identical.
• Tested node_repl with --disable-sandbox; both discovery calls still returned the same spawn EPERM.
• In a controlled fresh-task A/B, temporarily omitted CODEX_CLI_PATH from only the generated node_repl environment. Both calls still returned spawn EPERM; the original safe configuration was immediately restored.

No helper executable was launched directly, and no registry, manifest, ACL, plugin cache, or Windows security setting was manually modified.

Expected behavior

sky.list_apps() and sky.list_windows() should either return their discovery results or provide a specific supported-host diagnostic. They should not fail at the Node child-process creation layer when the official signed helper and bundled runtime are present.

Possible version/transport mismatch

The Desktop-generated environment advertises a Computer Use native pipe, but the bundled @oai/sky 0.6.2 Windows client still attempts to spawn its own helper and does not consume the native-pipe environment variables in its JS code. This may indicate a host/runtime contract mismatch.

Could the Windows Desktop runtime be updated so that either:

1. the native-pipe transport is actually used by the bundled client, or
2. the signed helper spawn is permitted through the supported node_repl policy?

Related reports

• #27278 - node_repl sandbox recovery but Computer Use still unavailable
• #25391 - Windows Computer Use native pipe path unavailable
• #26501 - bundled marketplace/runtime reconciliation failures
• #26587 - Windows Computer Use native pipe missing

None of those reports appears to contain this exact helper_transport.js -> child_process.spawn -> EPERM failure with an intact signed helper and complete plugin/runtime installation.

Privacy

All user names, host names, local task IDs, account details, window/app content, pipe identifiers, and full local paths have been omitted or replaced with placeholders.