Windows Computer Use cannot discover native apps even after js_repl workaround #45148

Activity

1. davidosullivan

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Sep 13, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   computer-use

   on Sep 13, 2026
3. github-actions commented on Sep 13, 2026

   

   github-actionsBot

   on Sep 13, 2026 – with GitHub Actions

   Contributor

   More actions

   Potential duplicates detected. Please review them and close your issue if it is a duplicate.

   • Windows Computer Use exposes only browser surface; sky service is not configured #44186
   • Windows Computer Use is enabled, but native desktop app enumeration is empty #44393
   • Windows Computer Use cannot access native applications #44481
   • Cannot list and use any app other than Chrome. #44161
   • [Windows][Computer Use] Native app requests are incorrectly routed to browser-only mcp__cua_repl, causing sky RPC failure #44986

   Powered by Codex Action
4. davidosullivan commented on Sep 17, 2026

   

   davidosullivan

   on Sep 17, 2026

   Author

   More actions

   Could an OpenAI maintainer confirm the status of native Windows app control in Computer Use?

   This is more than a convenience issue: without native-app access, Codex cannot operate or validate GUI-first workflows in tools such as Blender, Photoshop, Unity, or locally built desktop applications. In my environment, Computer Use consistently exposes only the in-app browser and returns apps: [] for native Windows applications, despite the plugin being installed/enabled and the target app visible in the active desktop session.

   Is this currently an acknowledged regression, an intentionally limited rollout, or a configuration issue with a documented workaround? If it is a regression, is there an issue we should track for a fix?
5. davidosullivan commented on Sep 17, 2026

   

   davidosullivan

   on Sep 17, 2026

   Author

   More actions

   It seems to work if you switch to Astra first (and then switch back) see here #45365 - its still super slow tho, nothing even close to the promo video
6. pirolid commented on Sep 20, 2026

   

   pirolid

   on Sep 20, 2026

   Last edited by pirolid

   More actions

   Additional Windows 11 reproduction: native Computer Use never starts

   Environment

   • Codex Desktop version: OpenAI.Codex 26.908.4834.0
   • Bundled Computer Use skill version: 26.908.40834
   • Platform: Windows 11 x64
   • Subscription: ChatGPT Business workspace with a paid seat
   • Computer Use: enabled
   • Computer Use > Any App: enabled
   • Model: GPT-5.6 Luna Light

   Reproduction

   I opened a standard Windows Notepad window and left it visible and unobstructed. I started a fresh Codex Desktop task and asked Computer Use to move the mouse to Notepad, click inside the document, type a short message, save it to Downloads, and leave the window open.

   The native Computer Use control surface never became available. Codex did not take control of the desktop, move the mouse, click, type, or attempt to save the file. It stopped immediately at the initial access stage and reported that no native Windows applications were available or that only browser tabs were exposed.

   Therefore, the issue is not only that Notepad was missing from an application list. Native Windows computer control never started.

   This reproduces the issue's core behavior on Windows 11: a fresh local task cannot establish native Computer Use even though a native Windows application is already open and visible.

   For comparison, GPT-6 Astra Light later initialized native Computer Use and completed the same Notepad task on the same computer. That comparison may help identify a model-dependent initialization or tool-routing problem, but the primary failure is the inability of the fresh GPT-5.6 Luna task to start native computer control.

   
7. pirolid commented on Sep 20, 2026

   

   pirolid

   on Sep 20, 2026

   Last edited by pirolid

   More actions

   I can reproduce this symptom, and I found a prompt-based workaround that worked on Windows 11.

   The important detail is that apps: [] does not necessarily mean Calculator or another native app is absent. In my case, the task had selected the browser-only Computer Use surface, so native Windows app APIs were not available. The native helper itself was usable once the task was explicitly directed to the native backend.

   Try starting the task with this instruction:

   Use the native Windows Computer Use backend, not browser-only computer control. Initialize the native Sky runtime with:

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

   Then call sky.list_apps(), locate the running Calculator window, retrieve that returned window, activate it, and inspect it with sky.get_window_state().

   I tested this approach with GPT-5.6 Luna. It detected and controlled Blender on the same Windows machine, and I also verified it with Notepad. The native app was detected and the task could interact with the actual desktop window.

   This also explains why calling cua.getApp(...) can fail: the browser-oriented cua surface does not expose the native Windows app methods. The workaround is to force the model to use the native node_repl/Sky Computer Use surface.

   I would treat this as a tool-discovery or session-bootstrap problem rather than a Calculator-specific problem. The long-term fix would be automatic native-backend selection whenever Any App is enabled.

   

   👍React with 👍1Reacted by pie90273