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
-
Start a fresh projectless task in Codex Desktop for Windows.
-
Read the bundled Computer Use skill guidance and confirmations.
-
Initialize the bundled package through the documented node_repl path:
const { sky } = await import("@oai/sky");
-
Call only the read-only discovery APIs:
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:
- the native-pipe transport is actually used by the bundled client, or
- the signed helper spawn is permitted through the supported
node_repl policy?
Related reports
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.
Summary
On Codex Desktop for Windows, the bundled Computer Use skill and
node_repltool are both available, but the two lowest-risk discovery calls fail before the native helper can start: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
26.803.5235.026.803.415150.147.0@oai/sky:0.6.27.6.4, Core, x64unelevatedMinimal reproduction
Start a fresh projectless task in Codex Desktop for Windows.
Read the bundled Computer Use skill guidance and confirmations.
Initialize the bundled package through the documented
node_replpath:Call only the read-only discovery APIs:
Both calls fail immediately. No app/window content, screenshots, activation, or input actions are involved.
Exact error
Both calls return:
Error properties:
The failure occurs before the helper protocol or Windows UI discovery returns any data.
Local validation
codex-computer-use.exeexists in the active@oai/skypackage.node_repl.exe, and@oai/skypackage in the active runtime are byte-identical to the copies embedded in the installed MSIX.node_replenvironment includesSKY_CUA_NATIVE_PIPEandSKY_CUA_NATIVE_PIPE_DIRECTORY(values omitted).@oai/sky0.6.2 does not reference either environment variable in its JS package. Its Windows transport unconditionally calls Nodechild_process.spawn()for the helper.sky.documentationis not exported by@oai/sky0.6.2, although static plugin docs are present. Reading those static docs resolves the documentation mismatch but does not affect this transport failure.node_repl.Repair attempts that did not change the result
node_replwith--disable-sandbox; both discovery calls still returned the samespawn EPERM.CODEX_CLI_PATHfrom only the generatednode_replenvironment. Both calls still returnedspawn 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()andsky.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/sky0.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:
node_replpolicy?Related reports
None of those reports appears to contain this exact
helper_transport.js -> child_process.spawn -> EPERMfailure 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.