Windows Codex Desktop: @Computer never exposes native Computer Use tools even after Repair and full reinstall

Open 💬 2 comments Opened Jun 22, 2026 by abbbit
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What issue are you seeing?

On Windows Codex Desktop, typing @Computer never exposes the native Computer Use tool in the active thread.

From the user side, Computer Use appears enabled in settings, but the actual model-facing desktop control tools are missing. The available tools in-session remain ordinary tools/connectors only (for example Codex app/thread tools, GitHub, Gmail, Photoshop), with no native Windows observe/click/type tools.

This persisted after:

  • normal restarts
  • Windows "Repair" for the app
  • full uninstall + reinstall

What steps can reproduce the bug?

  1. Install Codex Desktop from Microsoft Store on Windows.
  2. Open Codex and enable Computer Use.
  3. Start a new thread.
  4. Type:
@Computer view the current desktop window
  1. Check the actual tool list / tool discovery results.

What happened?

@Computer does not expose native Computer Use tools.

Observed symptoms:

  • no native Computer Use / Node REPL / desktop-control tools appear in the active session
  • tool_search still shows only ordinary app/connectors
  • codex_apps_tools / codex_app_directory cache files do not contain:
  • computer-use
  • openai-bundled
  • node_repl
  • browser
  • chrome
  • Codex Desktop tray icon sometimes appeared blank during this debugging cycle
  • Computer Use settings previously showed mojibake / garbled entries in the always-allowed apps list
  • earlier in the same failure cycle, Windows also showed a codex-windows-sandbox-setup.exe module-not-found dialog

What did you expect to happen?

After typing @Computer, the active thread should expose the model-facing Computer Use tools so Codex can actually observe and control Windows apps.

Environment

  • OS: Windows 11 x64
  • Codex Desktop package: OpenAI.Codex_26.616.6631.0_x64__2p2nqsd0c76g0
  • Install path:

C:\Program Files\WindowsApps\OpenAI.Codex_26.616.6631.0_x64__2p2nqsd0c76g0

  • Time observed: 2026-06-22

Key evidence

The local cua_node runtime exists and includes the expected executables:

  • node.exe
  • node_repl.exe
  • codex-computer-use.exe

But the current session still does not receive Computer Use tools.

During debugging, local app logs also showed repeated bundled runtime / bundled marketplace failures from the Windows Store package path, including:

  • bundled_executable_relocation_failed
  • browser_use_setup_failed ... reason=node-repl-missing
  • computer-use native pipe helper paths unavailable
  • plugin_marketplace_folder_write_failed
  • bundled_plugins_marketplace_resolve_failed

A manual PowerShell copy test from WindowsApps to user-writable directories reproduced the same class of failure with:

The specified file could not be encrypted.

Affected examples included:

  • bundled computer-use plugin manifest copy
  • bundled cua_node files such as CHANGELOG.md

Additional notes

Windows "Repair" did change one thing: C:\Users\fccvs\.codex\computer-use\config.json became writable again and Codex was able to update it.

However, even after Repair and then a full uninstall/reinstall, the core problem remained unchanged:

  • no computer-use in session tool discovery
  • no openai-bundled entries in generated app/tool cache
  • @Computer still unusable in practice

This may be related to existing Windows bundled-plugin / Computer Use registration issues, but this report adds a case where both Repair and full reinstall still do not recover the model-facing Computer Use tool exposure.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 2 months ago

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

  • #28197
  • #28493
  • #28775
  • #27907
  • #27865

Powered by Codex Action

zemeng5208 · 16 days ago

I maintain WinBridge Recovery for Windows Codex Desktop local plugin/runtime recovery: https://github.com/zemeng5208/winbridge-recovery

The local evidence here is directly relevant to the project's Application Protected/runtime-materialization work: the official CUA runtime exists, but Desktop logs show bundled executable relocation and marketplace failures, node-repl-missing, missing Computer Use helper paths, and manual WindowsApps copy tests fail with the encryption-related error. That can leave the package, user runtime/cache, and model-facing state split across different versions/levels of completeness.

WinBridge v3.1.1 uses a byte-stream (FileStream) copy path plus source/destination SHA-256 verification for official resources, validates the current package/manifest versions, and rebuilds inconsistent user-owned marketplace/cache/CUA runtime state through staging and rollback rather than altering WindowsApps.

I want to keep one limitation explicit: Application Protected/EFS recovery is still marked experimental in the project. And even if the local runtime/cache is reconstructed successfully, WinBridge cannot guarantee that the Desktop host will inject the trusted node_repl/Computer Use tools into the active thread; if all local layers are healthy and tool discovery is still empty, that remaining layer is upstream.

It does not decrypt, take ownership of, patch, or re-sign the Store package.