[Windows] Computer Use surface is incorrectly gated to Darwin, leaving @oai/sky unregistered

Environment

OS: Microsoft Windows NT 10.0.19045.0 x64
Codex Appx: 26.901.6511.0
Bundled/plugin version: 26.901.51231
@oai/sky: 0.6.26
@oai/cua: 0.2.4
@oai/browser-desktop: 0.1.1

Summary

The Windows Computer Use backend appears to be present and functional, but the Codex main-process CUA surface-selection logic excludes the computer surface because of a Darwin-only platform gate.

As a result, normal startup produces:

CUA_REPL_ENABLED_SURFACES="browser"

The unified-computer-use runtime then starts with:

browser=true
computer=false

Consequently, the sky Trusted RPC service is not registered.

Minimal reproduction

1. Start Codex normally on Windows.
2. Inspect the active CUA runtime state:

await cua.getState();

Observed:

apps: []
browsers: 3

3. Import and call the Windows Computer Use API:

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

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

Both calls fail with:

Error: Trusted RPC service is not configured: sky

Expected behavior

When the Computer Use feature is enabled and the Windows native backend is available, the computer surface should be included in the CUA surface list.

The runtime should receive:

CUA_REPL_ENABLED_SURFACES="browser,computer"

and initialize with:

browser=true
computer=true

The Trusted RPC mapping should then include:

browser -> @oai/browser-desktop/service
sky     -> @oai/sky/service

Actual behavior

Read-only inspection of the Codex main-process bundle found selector logic equivalent to:

let computerSurfaceEligible =
  browserEligible &&
  runtimePaths.platform === "darwin" &&
  features.computerUse &&
  computerUsePaths.enabled &&
  computerUsePaths.serviceAppPath != null;

let surfaces = [];

if (browserEligible && browserBackends.length > 0) {
  surfaces.push("browser");
}

if (computerSurfaceEligible) {
  surfaces.push("computer");
}

On this Windows system:

runtimePaths.platform = "win32"

Therefore the platform condition evaluates false and the selected surfaces are:

["browser"]

The .mcp.json writer then stores:

CUA_REPL_ENABLED_SURFACES="browser"

unified-computer-use/scripts/launch.mjs consequently derives:

browser=true
computer=false

and does not register:

sky -> @oai/sky/service

Diagnostic evidence

The following backend components were verified to exist and initialize:

• @oai/sky package
• @oai/sky/service
• Windows codex-computer-use.exe
• Windows native helper
• Native named pipe
• Native pipe startup reported startup ready
• Materialized Computer Use plugin files
• Bundled unified-computer-use runtime

The third-party browser-use/browser-harness Skill was also checked. It does not register or override sky and does not participate in NODE_REPL_TRUSTED_SERVICES.

Decisive isolated A/B experiment

No app.asar, feature flag, active .mcp.json, system environment variable, registry entry, cache, or third-party plugin was modified.

A separate fresh CUA child was started with the following environment variable set before process creation:

CUA_REPL_ENABLED_SURFACES=browser,computer

The fresh child actually reported:

setupOptions.browser=true
setupOptions.computer=true

Its Trusted RPC mapping included:

browser -> @oai/browser-desktop/service
sky     -> @oai/sky/service

The following calls then succeeded:

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

list_apps() successfully enumerated existing Windows applications, including Microsoft Edge, ChatGPT, Explorer, Chrome, Blender, Task Manager, Photoshop, OBS, and others.

list_windows() successfully enumerated the current Windows windows.

This confirms that, when the computer surface is enabled:

Windows @oai/sky backend: working
Windows native helper: working
Native pipe: working
Trusted RPC sky service: working

The isolated child was subsequently terminated.

The active .mcp.json remained unchanged. Its SHA256 before and after the experiment was identical:

E00CE9939E26DA8C5958F21B94F23575AF8976FF374765AE0B5EA1F3484F963F

No persistent environment variables were changed.

Why this is likely not an installation or environment issue

The same installed Windows backend, native helper, named pipe, and @oai/sky package successfully handled both list_apps() and list_windows() in a fresh child process when browser,computer was supplied before launch.

The failure occurs only in the normal Codex startup path, where the main process selects:

CUA_REPL_ENABLED_SURFACES="browser"

before unified-computer-use is launched.

The evidence suggests that the main-process CUA surface-selection logic is gating the computer surface to Darwin, even though the Windows Computer Use backend is present and functional.

Request for investigation

Please inspect the main-process CUA surface-selection path, especially:

cuaReplSurfaces
Windows computerUseNodeRepl path
platform gating around the computer surface
CUA_REPL_ENABLED_SURFACES generation

The intended fix is not asserted here; the request is to verify whether the Windows surface-selection logic is incorrectly constrained by the Darwin platform check.

Start with the main-process cuaReplSurfaces path and inspect the Windows computerUseNodeRepl handling, platform gating, and CUA_REPL_ENABLED_SURFACES generation. Compare normal Windows startup with the isolated browser,computer experiment described in the issue. Done means the selection logic is verified and, when the Windows backend is available, startup enables the computer surface and registers @oai/sky/service.