Windows Computer Use fails before window enumeration with `spawn EPERM` after reinstall/restart

Summary

On Windows, the supported Codex Desktop Computer Use path now fails before it can enumerate or select any window. A fresh @Computer request with Calculator visible returns spawn EPERM during Computer Use startup.

This is not a claim that the internal @oai/sky API is public. It is included only as the packaged-plugin diagnostic requested by the installed Computer Use workflow: sky.list_windows() returns spawn EPERM, while the bundled instructions also call sky.documentation("guidance") but the supplied runtime reports that method is not a function.

Environment

• Codex Desktop: 26.803.5235.0
• Bundled Computer Use plugin: 26.803.41515
• Windows: 10.0.26200.8875 (25H2)
• Time zone: Europe/Amsterdam

Reproduction

1. Install/enable Computer Use through the Codex UI.
2. Fully restart Codex.
3. Start a fresh task with a visible Calculator window and ask Computer Use only to identify it, without clicking or typing.
4. Computer Use fails before window enumeration or target selection with spawn EPERM.

What was checked

• The same documented plugin remove/reinstall, full app restart, and fresh-session test were completed; the failure remained.
• The currently installed app package reports healthy status, and the current Computer Use cache is present.
• Read-only Windows event checks in the exact +/-2 minute failure window found no matching Code Integrity Operational (3033/3077/3089/3118), AppLocker EXE/DLL, Defender Operational, or Security event.
• No security policy, ACL, registry, antivirus, or elevation workaround was changed.

Regression window

Computer Use window enumeration was directly observed working on 2026-07-31. The first directly recorded spawn EPERM was 2026-08-05, before the later app/plugin refresh; the current refresh did not recover it.

Request

Please identify the child/helper launch path behind this Computer Use failure and provide a supported remediation or an engineering reference. This appears related to the broader open Windows child-process/sandbox reports #21470 and #35070, but differs from the closed native-pipe report #26587 and from #25162 because there is no matching ACL-setup error or exact-time Windows block event here.