Windows: unified Computer Use facade omits Sky native methods when browser service is also registered #42941

Summary

On Windows Codex Desktop 26.901.41600, the unified Computer Use facade initializes and exposes the browser service, but does not expose the registered Sky/Windows native Computer Use service. This makes native desktop automation unavailable even though the bundled Sky client implements it.

This is distinct from reports where the native helper or model-facing computer tool is unavailable: the unified cua facade is present and browser methods work, but its trusted-service merge appears to omit Sky methods.

Environment

• Windows 11 x64
• Codex Desktop: 26.901.41600 (Sep 5, 2026)
• unified-computer-use plugin: 26.901.41600
• Bundled @oai/sky: 0.6.26
• Windows-native task (not WSL)

Actual behavior

The unified launcher starts node_repl with both trusted services:

{
  browser: "@oai/browser-desktop/service",
  sky: "@oai/sky/service",
}

But runtime introspection shows only the browser-facing facade:

Object.keys(cua)
// [
//   "initialize", "getState", "browsers", "getBrowser",
//   "createBrowserTab", "getTab", "listBrowsers", "listTabs"
// ]

No Sky/native methods are exposed, including list_apps, list_windows, get_window, launch_app, get_window_state, activate_window, click, scroll, drag, press_key, or type_text. Browser control continues to work.

Expected behavior

With both services registered, cua should preserve the browser API and expose the documented Windows Sky native API (currently snake_case, e.g. cua.list_apps()). The trusted-service loader/merger should not silently drop the second service.

Safe reproduction

1. On Windows, start a fresh Codex Desktop task with unified Computer Use enabled.
2. Run only:

await cua.initialize();
Object.keys(cua);

3. Observe browser methods only; typeof cua.list_apps and typeof cua.list_windows are "undefined".

No application launch, input, or destructive action is needed.

Why this likely is not only a naming mismatch

The bundled Sky Windows client itself implements the snake_case methods above. The reported facade contains no equivalent camelCase native methods either. The evidence therefore points to trusted-service registration/loading or facade merging rather than just a listApps vs. list_apps documentation mismatch.

Request

Please verify the trusted-service loading and merge behavior for a node_repl session initialized with both @oai/browser-desktop/service and @oai/sky/service, and add regression coverage that asserts both the browser API and Windows native API are retained.