[Windows] Native Computer Use app inventory is empty; persistent node_repl workaround works without switching models

[BFTwarrior]

Summary

I am reporting a reproducible Windows native Computer Use initialization failure. Browser Computer Use works, but the native Windows application inventory is empty (apps: []), so native apps such as WeChat and Notepad cannot be discovered or controlled.

The issue appears to be in the initialization / bridge path, not in the target applications and not an intentional limitation of GPT-5.6.

How I discovered this

Today, I connected Codex through a third-party API relay configured with CC Switch. Codex reported that initialization failed because the authentication token was missing or unavailable. My original intention was simply to ask whether that token error was normal.

Because I had lost confidence in Computer Use, I installed the third-party Windows-MCP desktop-control tool as a fallback. I also added an instruction saying that if Computer Use desktop control failed, Windows-MCP should be started and the task should continue with it.

Then one task unexpectedly initialized Computer Use successfully. I asked that task how it had managed to do it. It returned the fallback prompt described below. I tried that prompt directly. The persistent node_repl path imported @oai/sky, called sky.list_apps(), and recovered native Windows application discovery. After that, Computer Use could be started reliably without switching models.

I am sharing this now so other users can try it and report whether the workaround generalizes. I am not claiming that the authentication-token error, CC Switch, Windows-MCP, and the native Windows bridge always have the same root cause. They are part of the discovery path, but they should be tested separately.

Environment and affected versions

• OS: Windows 11 Home, build 26200, x64.
• Codex / ChatGPT Desktop: reproduced on 26.831.21537 and 26.901.51231.
• Public reports show the same failure family as early as 26.730.8199.0 and 26.803.5235.0.
• The currently documented affected range is therefore at least 26.730.8199.0 through 26.901.51231. I am not claiming that every build in between is affected.
• Models tested: GPT-5.5 and GPT-5.6-series models.

Symptoms

After asking Computer Use to initialize:

• Browser control works.
• Desktop control is reported as unavailable.
• The native Windows application list is empty (apps: []).
• Depending on the run, getApp / listApps are unavailable, or the runtime reports errors such as Trusted RPC service is not configured: sky, trusted Node process exited unexpectedly, or setup refresh had errors.
• Native applications such as WeChat and Notepad cannot be discovered, even when they are open, visible on the active desktop, and running normally.

This is confusing because the UI says that Computer Use is enabled and the browser surface works. It looks like the native Windows bridge fails to initialize while the browser bridge remains alive.

Troubleshooting already attempted

I have tried all of the following:

1. Disabled and re-enabled the Computer Use plugin and skill.
2. Uninstalled and reinstalled the Computer Use plugin.
3. Restarted Codex / ChatGPT Desktop.
4. Fully rebooted Windows.
5. Tested in a new empty conversation without a project or workspace.
6. Kept the target native application visible on the active desktop and ran it normally, not as administrator.
7. Reinstalled the ChatGPT / Codex application, and even reinstalled Windows on the affected system.
8. Confirmed that browser Computer Use continued to work while native app discovery failed.

None of these steps reliably fixed the cold-start problem.

Older workaround: switch models

The old workaround was:

1. Switch to GPT-5.5.
2. Initialize native Computer Use successfully under GPT-5.5.
3. Without closing Codex Desktop or resetting Computer Use, switch the same live task back to a GPT-5.6-series model.

After this bootstrap, the GPT-5.6-series model could often reuse the already initialized native Computer Use session. This worked, but it is expensive, awkward, and should not be required for a basic desktop-control initialization.

New workaround: persistent node_repl

The following workaround has been tested successfully. It does not require switching models.

First ask to initialize desktop control. When the result says that desktop control is unavailable, browser control is available, and the native application list contains zero apps, send this prompt:

Exact workaround prompt (English translation)

When `cua_repl` initialization fails due to a missing authentication token or a similar initialization error, do not conclude that desktop control is unavailable. Instead, use persistent `node_repl` to execute `const { sky } = await import("@oai/sky"); globalThis.sky = sky;`, then initialize via `sky.list_apps()` and continue with desktop control.

The original Chinese prompt is preserved verbatim in the Chinese section below.

After that, the persistent node_repl session can load @oai/sky, run sky.list_apps(), and restore native Windows application discovery. On my machine it returned approximately 40 applications, including WeChat, and the native WeChat window could then be read successfully.

I have tested this method twice without switching models, and both tests succeeded.

Important limitation

This is a workaround, not a mature fix. It depends on a persistent node_repl session and may be sensitive to the lifetime of the current task or runtime. I cannot yet claim that it is guaranteed to survive every cold start or every future update. However, it has been successful in essentially all of our repeated tests so far.

Requested fix

When cua_repl initialization fails but the persistent node_repl runtime is still usable, Computer Use should automatically fall back to the documented @oai/sky initialization path and call sky.list_apps() before reporting that desktop control is unavailable.

At this point, this no longer looks like an obscure edge case; it looks like a basic initialization path that was never given a proper regression test. Several consecutive builds have shipped with a broken native-app bridge, while the browser path remains functional, and users are expected to discover an undocumented model-switching ritual or a hidden fallback prompt on their own. If a one-line sky.list_apps() bootstrap can restore the feature, then allowing the product to repeatedly report "desktop control unavailable" is not a technically difficult limitation - it is a release-quality failure. The fact that users had to reverse-engineer the fallback is a particularly unflattering sign that the Computer Use Windows path is being shipped without even basic end-to-end verification.

Related reports

• #42214
• #43373
• #43596
• #43498
• #37415
• #37284

---

中文说明

我报告的是一个可以稳定复现的 Windows 原生 Computer Use 初始化问题。浏览器 Computer Use 正常，但是 Windows 原生应用列表为空（apps: []），因此无法发现或控制微信、记事本等原生应用。

这个问题看起来出在初始化或桥接路径，而不是目标应用本身，也不是 GPT-5.6 有意限制原生 Windows 应用。

我是怎么发现这个问题的

今天我通过 CC Switch 配置的第三方中转站 API 连接 Codex。Codex 显示初始化认证令牌失败或认证令牌不可用。我原本只是想先询问这种令牌错误是否正常。

因为当时对 Computer Use 已经不抱太大希望，我安装了第三方桌面控制工具 Windows-MCP 作为备用方案，并加入了这样的指示：如果 Computer Use 的桌面控制失败，就启动 Windows-MCP 继续任务。

但是，之后有一个任务意外成功启动了 Computer Use。我追问它是怎么做到的，它给出了下面所写的备用提示词。我直接使用这段提示词后，持久化的 node_repl 成功加载 @oai/sky，执行 sky.list_apps()，恢复了 Windows 原生应用发现。之后不切换模型也可以比较稳定地启动 Computer Use。

我今天把这个方法分享出来，是想让其他用户也尝试一下，看看它是否具有普遍性。我并不声称认证令牌错误、CC Switch、Windows-MCP 和 Windows 原生桥接一定有同一个根因；它们是这次发现过程中的不同环节，应该分别验证。

环境和已知受影响版本

• 系统：Windows 11 Home，版本号 26200，x64。
• Codex / ChatGPT Desktop：在 26.831.21537 和 26.901.51231 上复现。
• 公开报告显示，同一故障族最早至少可以追溯到 26.730.8199.0 和 26.803.5235.0。
• 因此目前能记录的受影响范围至少是 26.730.8199.0 到 26.901.51231，但不能据此断言中间每一个版本都必然受影响。
• 测试过的模型：GPT-5.5 和 GPT-5.6 系列模型。

现象

请求 Computer Use 初始化后：

• 浏览器控制正常。
• 桌面控制被报告为不可用。
• Windows 原生应用列表为空（apps: []）。
• 根据具体运行情况，getApp / listApps 不可用，或者出现 Trusted RPC service is not configured: sky、trusted Node process exited unexpectedly、setup refresh had errors 等错误。
• 即使微信、记事本已经打开，窗口可见，并且在当前桌面正常运行，也无法被发现。

这很容易误导用户，因为界面显示 Computer Use 已启用，浏览器控制也能用。实际情况像是原生 Windows 桥接没有初始化成功，而浏览器桥接仍然正常。

已经尝试过的排查

我已经尝试了以下所有方法：

1. 关闭并重新启用 Computer Use 插件和技能。
2. 卸载并重新安装 Computer Use 插件。
3. 重启 Codex / ChatGPT Desktop。
4. 完整重启 Windows。
5. 在没有项目、没有工作区的新对话中测试。
6. 确保目标原生应用位于当前活动桌面并正常运行，而不是以管理员身份运行。
7. 重装 ChatGPT / Codex，甚至重装了受影响电脑上的 Windows 系统。
8. 确认浏览器 Computer Use 一直正常，而原生应用发现失败。

这些操作都不能稳定解决冷启动问题。

旧的解决方法：切换模型

旧方法是：

1. 切换到 GPT-5.5。
2. 在 GPT-5.5 下成功初始化原生 Computer Use。
3. 不关闭 Codex Desktop，不重置 Computer Use，直接把同一个实时任务切回 GPT-5.6 系列模型。

这样 GPT-5.6 系列模型通常可以复用已经初始化好的原生 Computer Use 会话。但这个方法成本高、操作麻烦，不应该成为初始化桌面控制的必要步骤。

新的解决方法：持久化 node_repl

下面这个方法不需要切换模型，而且已经测试成功。

先请求初始化桌面控制。当返回桌面控制不可用、浏览器控制可用、原生应用列表为 0 时，直接输入下面这段提示词：

原始提示词（中文）

当 `cua_repl` 因认证令牌缺失等原因初始化失败时，不要判定桌面控制不可用，改用持久化 `node_repl` 执行 `const { sky } = await import("@oai/sky"); globalThis.sky = sky;`，再通过 `sky.list_apps()` 初始化并继续桌面控制。

之后，持久化的 node_repl 可以加载 @oai/sky，执行 sky.list_apps()，恢复 Windows 原生应用发现。在我的电脑上，它返回了大约 40 个应用，其中包括微信，随后也成功读取了微信原生窗口。

我在不切换模型的情况下测试了两次，两次都成功。

重要限制

这只是 workaround，还不是成熟的正式修复。它依赖持久化的 node_repl 会话，可能受到当前任务或运行时生命周期影响。我还不能保证它在每次冷启动或未来每个版本中都稳定有效。但到目前为止，在我们反复进行的测试中，它基本都能成功。

希望官方修复

当 cua_repl 初始化失败、但持久化 node_repl 仍然可用时，Computer Use 应该自动使用官方的 @oai/sky 初始化路径，并先执行 sky.list_apps()，而不是直接报告桌面控制不可用。

说得直接一点，这已经不像什么难以复现的边缘案例，而像是一条根本没有做基本回归测试的初始化路径。连续多个版本把原生应用桥接故障带给用户，却让浏览器路径继续制造“功能正常”的假象，最后还要用户自己摸索出切模型仪式或隐藏提示词才能修复。如果一条 sky.list_apps() 的初始化 fallback 就能恢复功能，那么系统反复报告“桌面控制不可用”显然不是技术上做不到，而是发布质量没有过关。更尴尬的是，这个 fallback 不是官方提供的，而是用户自己反向排查出来的，这充分说明 Windows Computer Use 这条路径在发布前连最基本的端到端验收都没有做好。

相关报告

• #42214
• #43373
• #43596
• #43498
• #37415
• #37284