Windows Computer Use: native-app discovery fails with Luna/Terra/Sol but succeeds with Astra

Codex App version

Installed Windows package: OpenAI.Codex 26.908.4834.0 (queried with Get-AppxPackage, not copied from the About dialog).

Bundled Computer Use skill version: 26.908.40834.

Subscription

Not collected.

Platform

Windows notebook. Reported OS version: Microsoft Windows NT 10.0.26200.0.

Issue

Native Windows Computer Use appears to depend on the selected model. On this machine, I observe that gpt-5.6-luna, gpt-5.6-terra, and gpt-5.6-sol fail to discover native-app Computer Use, while Chrome Computer Use remains available. Switching to gpt-6-astra allows native Windows app discovery and interaction to succeed.

Computer Use > Any App is enabled, and Chrome's browser extension is installed and enabled. Restarting the desktop app did not resolve the reported failure before switching models.

The concrete task was to open the already-running LINE desktop app and summarize today's messages in a specified group. The failing attempt concluded that only browser control was available. A later attempt in the same conversation, after switching to Astra, discovered the native Windows tool path and successfully enumerated, activated, captured, and scrolled LINE.

Model comparison and evidence limits

The three failing-model outcomes above are my reported observations. The conversation transcript directly records one failed browser-oriented attempt and the subsequent successful native Windows attempt; it does not independently capture a controlled reproduction for each of the three failing models. The app had also been restarted before the successful attempt, so this is evidence of a model-associated problem, not proof of model-based backend gating.

Steps to reproduce

1. On a Windows notebook, enable Computer Use > Any App and have Chrome Computer Use available.
2. Open a native Windows app, such as LINE, with an active window.
3. Select gpt-5.6-luna, gpt-5.6-terra, or gpt-5.6-sol.
4. Explicitly invoke the Computer Use plugin and ask it to inspect or interact with the native app.
5. Observe whether the agent uses browser-only discovery, reports no native apps, or concludes that native-app control is unavailable.
6. Switch to gpt-6-astra and repeat the request on the same machine with Any App still enabled.
7. Compare whether the agent discovers the Node REPL tool and uses the bundled @oai/sky Windows API successfully.

Actual tool-call excerpts

These are excerpts from the task transcript, not backend diagnostic logs. Unrelated browser tabs, chat contents, account details, and local user paths are omitted.

Failed attempt through mcp__cua_repl.js:

await cua.getState();

The returned inventory contained apps: [], while Chrome and the in-app browser were listed. The tool instructions for this surface said native computer APIs were disabled.

globalThis.lineApp = await cua.getApp("LINE");

Exact error:

cua.getApp is not a function

Inspection of the available cua methods returned:

[
  "rewriteDocumentation",
  "getState",
  "browsers",
  "getBrowser",
  "createBrowserTab",
  "getTab",
  "listBrowsers",
  "listTabs",
  "initialize"
]

Successful attempt after switching to Astra used mcp__node_repl__js and followed the bundled Windows Computer Use skill:

if (!globalThis.sky) {
  const { sky } = await import("@oai/sky");
  globalThis.sky = sky;
}
globalThis.apps = await sky.list_apps();

Native app discovery returned LINE with isRunning: true and one window titled LINE. It also returned other native Windows applications.

globalThis.targetApp = apps.find(a => a.displayName === "LINE");
if (targetApp.windows.length !== 1) throw new Error("LINE window ambiguous");
globalThis.targetWindow = await sky.get_window({
  id: targetApp.windows[0].id,
  app: targetApp.windows[0].app
});
await sky.activate_window({ window: targetWindow });
globalThis.state = await sky.get_window_state({
  window: targetWindow,
  include_screenshot: true,
  include_text: true
});

The result included:

Window: "LINE", App: LINE.exe.

A valid screenshot and accessibility tree were returned. Subsequent sky.scroll(...) calls and window captures succeeded, allowing the original reading task to finish.

Expected behavior

Models offered for this workflow should consistently discover and use the installed Windows Computer Use capability when Any App is enabled. A browser-only cua inventory should not cause the agent to conclude that all native Windows control is unavailable when the bundled @oai/sky path can work.

If native Computer Use is intentionally restricted by model, that limitation should be explicit in the UI and tool/skill configuration.

Investigation notes

Please investigate model-dependent tool discovery, deferred-tool visibility, and routing between the browser-oriented cua_repl surface and the Windows node_repl / @oai/sky surface. The observed failure could be tool selection or skill-following rather than a failure of the native Windows helper itself; the successful attempt shows that the native helper can operate on this machine.

Related reports: #45148 (same apps: [] and cua.getApp is not a function symptoms), #44481 (native Windows access failure, but a different RPC error). This report adds the user-observed model comparison and the successful @oai/sky call sequence.

Start by comparing the failing mcp__cua_repl.js surface with the successful mcp__node_repl__js sequence using @oai/sky, then review related issues #45148 and #44481. Trace model-dependent tool visibility and routing; done means supported models consistently expose native Windows discovery, or the restriction is explicit in the UI and skill configuration.