Windows Computer Use Skill installed but native connection unavailable after update 26.5.27.31326

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

• #25507
• #25391
• #25511
• #25488

Powered by Codex Action

Additional reproducible case on the current Windows build.

Environment:

• Codex Desktop: 26.707.9981.0 (Microsoft Store/MSIX)
• Codex CLI: 0.144.2
• OS: Windows 11 Home, 10.0.26200, x64
• Computer Use plugin: 26.707.72221, installed and enabled
• Computer Use feature flag: true
• Trusted runtime: cua-node 0.0.4 / 20260713191736-ad8b1874340f-pr-1124580
• Node REPL runtime: 20260713.2
• Native Windows workspace (not WSL)

Observed behavior:

• New Codex Desktop threads load the Computer Use skill, but expose no Node REPL / trusted Windows execution entry point.
• No mcp__node_repl__js, node_repl js, js, or equivalent Computer Use execution tool is present in the thread tool set.
• A prompt that explicitly invokes computer-use@openai-bundled to list open applications cannot reach list_apps().
• Reproduces across multiple new threads after fully quitting and restarting Codex.
• Example affected thread/task ID: 019f6674-b368-7a43-8574-1a66e75c5c7c

Additional local evidence:

• The app updated while the per-user trusted runtime cache remained on an older June runtime (cua-node 0.0.1 / Node REPL 20260605.1).
• Copying the current bundled runtime out of the WindowsApps package with robocopy failed with Windows error 6000: "The specified file could not be encrypted." This matches the EFS/Application Protected packaging symptoms reported in #25220.
• A byte-for-byte copy using System.IO.File.ReadAllBytes/WriteAllBytes succeeded. The cached node_repl.exe SHA-256 then matched the current app package exactly.
• Browser, Chrome, and Computer Use plugins were synchronized to 26.707.72221 and reinstalled.
• codex doctor and strict config validation both report OK.
• Despite the synchronized runtime, matching hashes, enabled flags, app restart, and new threads, the trusted Windows/Node REPL entry point is still not injected.

This suggests two layers:

1. WindowsApps EFS prevents normal runtime/plugin reconciliation on affected machines.
2. Even after repairing the local runtime/cache mismatch, Codex Desktop still does not provision the trusted execution bridge into the thread.

A normal manually configured MCP server is not an equivalent workaround because it cannot reproduce the trusted native pipe and Codex turn/session metadata. Please investigate the Desktop tool-injection/host-service provisioning path for current 26.707 Windows builds.

I can reproduce the same underlying failure on a newer Windows desktop build.

Environment

• ChatGPT Plus
• ChatGPT/Codex desktop app version 26.803.41515 (released August 6, 2026)
• Computer Use plugin enabled

Observed behavior

• The Computer Use plugin page shows only Skills 1 → Computer Use.
• The expected MCP servers 1 → Computer-use section is completely absent.
• In a new, active Codex chat, a simple request to open Windows Calculator reports that Computer Use controls are unavailable in the session.
• Chrome control is installed and connected, so the failure appears specific to the local native Computer Use server/helper.

Troubleshooting completed

• Reinstalled the Computer Use plugin multiple times.
• Confirmed Windows Defender Protection History shows no blocked or quarantined items.
• Confirmed Computer Use is enabled and “Any App” is allowed.
• Ran Windows Repair on the current ChatGPT desktop app; the MCP server remained missing.
• Did not enable Full Access or use Windows Reset.

Diagnostic feedback ID from the affected Codex session: 919fe425-0f76-7792-b011-8fd3bef5c4c9

This suggests the native Computer Use server/helper is not being provisioned or registered at all, rather than starting and then failing to connect.

I maintain WinBridge Recovery, an independent Windows recovery/diagnostic tool for Codex Desktop local plugin/runtime state: https://github.com/zemeng5208/winbridge-recovery

The newer reports here are useful because they show two separate layers that should not be conflated. On affected machines, the Store update can leave the user-side CUA/Node REPL runtime and bundled plugin cache behind the current package, and Application Protected resources can block normal reconciliation. That local package -> runtime/cache mismatch is within WinBridge's scope: it checks package/plugin/runtime versions and hashes, reconstructs user-owned official-resource copies through verified staging, and validates helper paths/state afterward.

However, the 26.707 report also shows an important boundary: after the runtime was synchronized byte-for-byte and hashes matched, the trusted Node REPL/Computer Use execution bridge still was not injected. WinBridge should not claim to repair that host/tool-injection layer. Likewise, if 26.803 has complete current runtime/helper files but Desktop simply never provisions the native server into the session, that is an upstream Desktop runtime issue.

So for users here the tool may help answer and recover the first question — “are my marketplace/cache/runtime/helper files actually current and consistent?” — while deliberately stopping if those layers are healthy and the failure is the trusted bridge itself. It does not bypass feature gates, sandbox/trust policy, or patch the app package.