Windows Computer Use helper times out on list_apps and launch_app while list_windows works

Summary

On Windows Codex Desktop, Computer Use starts the native helper and can enumerate windows, but app discovery and launch requests consistently time out after the fixed 10s request budget.

This does not appear to be a missing helper binary or a totally dead pipe. list_windows succeeds quickly, while list_apps and launch_app time out.

Environment

• OS: Windows
• Codex Windows app: OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0
• Computer Use plugin: openai-bundled/computer-use/26.527.31326
• @oai/sky: 0.4.5-26568471749-e86e78c35d86
• Helper binary path exists:
• C:\Users\Lenna\.codex\plugins\cache\openai-bundled\computer-use\26.527.31326\node_modules\@oai\sky\bin\windows\codex-computer-use.exe

Reproduction

From the Codex Node REPL after following the bundled Computer Use bootstrap:

await setupComputerUseRuntime({ globals: globalThis });
await sky.list_windows();
await sky.list_apps();
await sky.launch_app({ app: "notepad.exe" });

Observed behavior

list_windows succeeds:

{
  "list_windows": {
    "ok": true,
    "durationMs": 631,
    "count": 1,
    "sample": [
      {
        "id": 1641246,
        "app": "process:C:\\Windows\\explorer.exe",
        "title": "Deze pc - Verkenner"
      }
    ]
  }
}

list_apps fails after about 10 seconds:

{
  "ok": false,
  "durationMs": 10022,
  "errorName": "Error",
  "errorMessage": "computer-use request timed out: list_apps"
}

launch_app also fails after about 10 seconds:

{
  "launch": {
    "ok": false,
    "errorMessage": "computer-use request timed out: launch_app"
  },
  "list_windows": {
    "ok": true,
    "durationMs": 160,
    "count": 1
  }
}

A clean reconnect/reset did not help:

1. Initial sky.list_apps() timed out.
2. Retry after a short wait timed out.
3. js_reset plus fresh Computer Use bootstrap timed out again.

Helper/process evidence

During a list_apps timeout, process monitoring showed the helper process does start:

codex-computer-use.exe --parent-pid 15036

The process remains visible during the 10s request window and then disappears after the timeout. So the helper is being spawned, but the request does not complete.

Codex desktop log evidence

Earlier desktop logs from the same app session show the helper path repair/startup path:

[computer-use-native-pipe] computer-use notify config ensure finished platform=win32 reason=missing-helper-path status=skipped
[computer-use-native-pipe] computer-use native pipe startup failed errorMessage="Windows Computer Use helper paths are unavailable"
...
[BundledPluginsMarketplace] bundled_plugin_install_requested pluginName=computer-use
[computer-use-native-pipe] computer-use notify config ensure finished platform=win32 status=repaired
[computer-use-native-pipe] computer-use native pipe startup ready pipePath=\\.\pipe\codex-computer-use-... platform=win32

The same desktop log also shows app-list related calls taking longer than the 10s Computer Use request budget, for example:

method=app/list durationMs=43244
method=app/list durationMs=11103

This may or may not be the same underlying app-catalog/app-enumeration path, but it matches the timeout scale seen from Computer Use.

Expected behavior

• list_apps should return installed/running apps or fail with a diagnostic error if app enumeration is unavailable.
• launch_app({ app: "notepad.exe" }) should either launch Notepad or return a specific error explaining why the launch path is unavailable.
• If app enumeration can legitimately exceed 10 seconds on Windows, the helper should either stream/cache/return partial results or use a longer budget for this path.

Actual behavior

• list_windows works, proving the pipe/helper is not completely unavailable.
• list_apps and launch_app consistently time out after ~10s with no more specific diagnostic.
• This prevents basic Windows Computer Use workflows such as opening Notepad.

Notes

This was observed immediately after Windows Computer Use became available in Codex 26.527, so it may be an early Windows helper/app-catalog regression rather than an app-specific issue.