Windows Codex app: Computer Use shows "Computer Use plugins unavailable" despite current docs saying Windows is supported

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

• #25962
• #26204
• #26078
• #26501
• #26399

Powered by Codex Action

Additional local diagnostics after inspecting the current Windows app package and user-level bundled marketplace cache:

Installed app package:
OpenAI.Codex_26.602.3474.0_x64__2p2nqsd0c76g0

App-bundled marketplace root:
C:\Program Files\WindowsApps\OpenAI.Codex_26.602.3474.0_x64__2p2nqsd0c76g0\app\resources\plugins\openai-bundled

App-bundled marketplace.json plugins:
sites, browser, chrome, computer-use, latex

App-bundled computer-use plugin.json:
name: computer-use
version: 26.602.30954
description: Control desktop apps on Windows from Codex through Computer Use.
policy: installation AVAILABLE in app marketplace.json

Active user bundled marketplace cache:
C:\Users\sobha\.codex\.tmp\bundled-marketplaces\openai-bundled

Active user marketplace.json plugins:
browser-use, latex-tectonic

So the current app package does contain the Windows computer-use plugin and marks it AVAILABLE, but the active user runtime marketplace cache is stale/partial and only exposes the older browser-use + latex-tectonic entries.

There is also an old staging directory:

C:\Users\sobha\.codex\.tmp\bundled-marketplaces\openai-bundled.staging-11a5d614-f78c-4336-9d83-c1592bcc062d

That staging directory contains skeletal chrome, computer-use, and latex plugin folders, but it is missing .agents\plugins\marketplace.json, so it appears an earlier bundled-marketplace promotion/sync did not complete cleanly.

Current hypothesis: this is not an account entitlement-only issue and not a missing app bundle issue. It looks like Codex is reading a stale user-level openai-bundled marketplace cache instead of the current app-bundled marketplace after update. Settings then shows the Computer Use page, but the runtime/plugin installer cannot discover computer-use from the active marketplace cache.

More diagnosis + local workaround attempt:

A normal Copy-Item from the installed app-bundled marketplace to the user marketplace cache fails with:

Copy-Item : The specified file could not be encrypted.

The source files in the WindowsApps Codex package are marked encrypted / application-protected:

C:\Program Files\WindowsApps\OpenAI.Codex_26.602.3474.0_x64__2p2nqsd0c76g0\app\resources\plugins\openai-bundled\.agents\plugins\marketplace.json
Attributes: Archive, Encrypted
cipher /c: E marketplace.json
Compatibility Level: Application Protected

...\plugins\computer-use\.codex-plugin\plugin.json
Attributes: Archive, Encrypted
cipher /c: E plugin.json
Compatibility Level: Application Protected

...\plugins\chrome\.codex-plugin\plugin.json
Attributes: Archive, Encrypted
cipher /c: E plugin.json
Compatibility Level: Application Protected

This explains why the bundled marketplace cache can end up stale/partial: ordinary copy/promotion from WindowsApps package files can fail on these protected files.

A byte-level read/write copy that does not preserve the encrypted attribute succeeds. I used that to rebuild:

C:\Users\sobha\.codex\.tmp\bundled-marketplaces\openai-bundled

from the current app package bundle. Result:

Files copied: 953
Active user marketplace.json plugins now:
sites, browser, chrome, computer-use, latex
computer-use plugin manifest exists: true
chrome plugin manifest exists: true

I also added the following config entries locally:

[plugins."computer-use@openai-bundled"]
enabled = true

[plugins."chrome@openai-bundled"]
enabled = true

Backups were created under:

F:\Agents\codex\backups\codex-computer-use-cache\20260605-011822

The stale active cache was moved to:

C:\Users\sobha\.codex\.tmp\bundled-marketplaces\openai-bundled.stale-20260605-011822

Current session tool discovery still does not show Computer Use, which is expected if plugin discovery is loaded at app/thread startup. Next verification step is to fully restart the Codex app and check Settings > Computer Use / a fresh thread.

Suggested product fix: bundled marketplace promotion on Windows should copy from application-protected WindowsApps package files using a data-only/byte-stream copy path or otherwise avoid preserving the application-protected EFS attribute, and should validate that the promoted user marketplace contains every plugin listed by the app-bundled marketplace manifest before replacing/keeping the active cache.

Chrome plugin / extension-specific follow-up after the bundled marketplace cache was repaired:

The Chrome plugin root is now present in the active bundled marketplace cache:

C:\Users\sobha\.codex\.tmp\bundled-marketplaces\openai-bundled\plugins\chrome

The plugin diagnostics report:

installed-browsers.js --json:
{
  "installed_browsers": [
    {
      "name": "Google Chrome",
      "path": "C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe"
    }
  ],
  "default_browser": {
    "schemes": {
      "http": { "prog_id": "MSEdgeHTM" },
      "https": { "prog_id": "MSEdgeHTM" }
    }
  }
}

chrome-is-running.js --json:
{
  "running": true,
  "processes": [ many chrome.exe processes ]
}

check-extension-installed.js --json:
{
  "extensionId": "hehggadaopoacecdllhhajmbjkdcmajg",
  "selectedProfileDirectory": "Default",
  "installed": false,
  "enabled": false,
  "profiles": [
    { "profileDirectory": "Default", "installed": false, "registered": false, "enabled": false, "selected": true },
    { "profileDirectory": "Profile 1", "installed": false, "registered": false, "enabled": false },
    { "profileDirectory": "Profile 2", "installed": false, "registered": false, "enabled": false }
  ],
  "exitCode": 2
}

check-native-host-manifest.js --json:
{
  "manifestPath": "C:\\Users\\sobha\\AppData\\Local\\OpenAI\\extension\\com.openai.codexextension.json",
  "registryKey": "HKCU\\Software\\Google\\Chrome\\NativeMessagingHosts\\com.openai.codexextension",
  "registryManifestPath": null,
  "expectedHostName": "com.openai.codexextension",
  "expectedExtensionId": "hehggadaopoacecdllhhajmbjkdcmajg",
  "expectedOrigin": "chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/",
  "exists": false,
  "correct": false,
  "problem": "Windows native host registry key does not exist: HKCU\\Software\\Google\\Chrome\\NativeMessagingHosts\\com.openai.codexextension; Native host manifest does not exist: C:\\Users\\sobha\\AppData\\Local\\OpenAI\\extension\\com.openai.codexextension.json"
}

The native host binary exists in the plugin cache:

C:\Users\sobha\.codex\.tmp\bundled-marketplaces\openai-bundled\plugins\chrome\extension-host\windows\x64\extension-host.exe

But the install artifacts were never created:

C:\Users\sobha\AppData\Local\OpenAI\extension   // missing
HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension // missing

So after the marketplace-cache repair, this has moved from “Chrome plugin not discoverable” to “Chrome plugin is present, but the plugin setup flow has not installed the Chrome Web Store extension or registered the native host.” The plugin docs say not to manually run scripts/installManifest.mjs; the supported recovery path is to reinstall the Chrome plugin from the Codex plugin UI, but this user reports that setup fails every time.

Update after re-checking locally on 2026-06-05:

The bundled marketplace cache has been repaired and now lists computer-use and chrome in addition to browser, sites, and latex.

Current local package/cache evidence:

• Codex app package: OpenAI.Codex_26.602.3474.0_x64__2p2nqsd0c76g0
• Active bundled cache: C:\Users\sobha\.codex\.tmp\bundled-marketplaces\openai-bundled
• Active marketplace plugins now include: sites, browser, chrome, computer-use, latex
• Computer Use plugin path exists: C:\Users\sobha\.codex\.tmp\bundled-marketplaces\openai-bundled\plugins\computer-use
• scripts\computer-use-client.mjs exists in that active plugin path
• .codex-plugin\plugin.json exists and declares computer-use version 26.602.30954

However, in the current Codex conversation, tagging @Computer loads the plugin/skill context but does not expose the required runtime tool for Windows automation. Tool discovery for node_repl js / mcp__node_repl__js / Computer Use returns other tools, but not the JavaScript runtime needed by the Computer Use plugin. So the package appears installed locally, but the thread still cannot actually use Computer Use.

Chrome plugin status has also narrowed:

• Codex Chrome Extension is installed and enabled in Chrome Default profile
• Extension version: 1.1.5_0
• Chrome is running
• Native messaging host is missing:
• registry key missing: HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension
• manifest missing: C:\Users\sobha\AppData\Local\OpenAI\extension\com.openai.codexextension.json

So Chrome is “installed but disconnected” because the Codex native messaging host was not installed/registered. The plugin troubleshooting docs say not to repair/install that host manually; the supported path is to reinstall/re-add the Chrome plugin from the Codex plugin UI.

Additional local evidence from the same Windows machine:

• Codex Desktop package: OpenAI.Codex_26.602.3474.0_x64__2p2nqsd0c76g0.
• Active bundled Computer Use plugin files are present and valid:
• ...\.codex\.tmp\bundled-marketplaces\openai-bundled\plugins\computer-use
• scripts\computer-use-client.mjs exists
• .codex-plugin\plugin.json exists
• Cached copy is also present:
• ...\.codex\plugins\cache\openai-bundled\computer-use\26.602.30954
• config.toml has [plugins."computer-use@openai-bundled"] enabled = true and the Computer Use notify = [...] entry is already installed.
• App package contains app\resources\node_repl.exe.
• The installed app bundle code appears to gate Computer Use startup on both desktopFeatureAvailability.computerUse and desktopFeatureAvailability.computerUseNodeRepl being true. The general turn feature list includes ComputerUse, but tool discovery never exposes the required Node REPL / js execution tool, and no Computer Use native-pipe process or startup log appears.
• state_5.sqlite.thread_dynamic_tools has no rows for repl, node_repl, computer, chrome, or browser for the affected threads.
• Current running MCP servers are only normal app/configured servers such as codex_apps, xcodebuildmcp, and openai-api-key-local-confirmation; no node_repl/Computer Use runtime is started.

This now looks less like missing plugin files and more like the computerUseNodeRepl / shared runtime bridge is not being provisioned or not being included in the desktop feature availability for this account/session on Windows.

Update: I found an app-code local override that may work around this on Windows:

CODEX_ELECTRON_ENABLE_WINDOWS_COMPUTER_USE=1

In the packaged Codex Desktop app code, on win32 this override appears to force both computerUse and computerUseNodeRepl to true before desktop feature availability is propagated. I set it at the Windows user environment level on the affected machine and confirmed HKCU\Environment\CODEX_ELECTRON_ENABLE_WINDOWS_COMPUTER_USE = 1.

This cannot affect already-running Codex processes; the app must be fully restarted before the runtime/tool exposure can be re-tested. If this fixes it, then the normal server/app availability state was leaving computerUseNodeRepl off even though the Computer Use plugin was installed and enabled. If it does not fix it after restart, the remaining failure is likely in the app-server/tool-building path after desktop feature availability is set.

You're not alone; I've run into the same problem.

Same symptom here on Windows (Settings → Computer use → "Computer Use plugins unavailable"). I traced a root cause on my machine that I haven't seen called out in the existing threads, sharing in case it helps.

**Root cause on my machine: the Statsig post-login client fails to bootstrap because user.custom.workspace_type is an invalid type, which fail-closes desktop feature availability and prunes Computer Use.**

Chain:

1. On every launch (and ~1s after every fresh login):

error [electron-message-handler] Statsig: error while bootstrapping post-login client
  ... "path": ["user","custom","workspace_type"], "message": "Invalid input"

The accepted union is string | number | boolean | array | undefined, so the value being sent is an object/null. (The value itself is logged as "sensitive", so I can't include it. My account may belong to more than one workspace — possibly relevant.)

1. With feature availability unresolved, the bundled-plugin reconcile treats Computer Use as feature-unavailable and prunes it:

info [bundled-plugins] bundled_plugins_reconcile_skipped_features_unavailable reason=...
info [BundledPluginsMarketplace] bundled_plugin_uninstall_requested reason=not_in_bundled_marketplace_plugin_names

%USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled\plugins\ ends up containing only chrome, even though the Store package ships computer-use at ...\app\resources\plugins\openai-bundled\plugins\computer-use\...\codex-computer-use.exe.

1. The native pipe then can't resolve the helper paths:

warning [computer-use-native-pipe] computer-use native pipe startup failed
  errorMessage="Windows Computer Use helper paths are unavailable"   (at ensureReadyPipePath)
info    [computer-use-native-pipe] computer-use notify config ensure finished reason=missing-helper-path status=skipped
info    [BrowserUseThreadConfig] computer_use_native_pipe_thread_config_skipped reason=not-ready

In app.asar: if (windowsHelperPath == null || windowsHelperTransportModulePath == null) throw Error("Windows Computer Use helper paths are unavailable").

Why I'm confident it's this gate and not version / cache / auth (all reproduced on my Windows 11 machine):

• Reproduced on 26.527.x, 26.601.2237.0, and 26.602.3474.0.
• Downgrading to 26.601.2237.0 — the exact build that works on my second Windows machine, signed into the same ChatGPT account — does not fix it.
• Full sign-out / sign-in does not fix it (the workspace_type error returns ~1s after login completes).
• Clean uninstall + reinstall, and moving aside the .codex plugin cache / bundled-marketplace staging, do not fix it.
• Browser Use works fine on the same machine (browser_use_availability_resolved available=true reason=available); only Computer Use is gated off — so the named-pipe / sandbox infrastructure itself is fine.

Looks related to #25253 (Statsig gate exposing a reduced plugin set), and #25795 / #25665 / #25571 (helper-paths / missing-helper-path). The new piece here is that the gate can fail because the Statsig client never bootstraps, due to the invalid workspace_type.

Suggested fixes:

1. Ensure user.custom.workspace_type is always a valid scalar (string/number/boolean) or undefined — it's currently serialized as an object/null for some accounts.
2. Make Statsig post-login bootstrap failure non-fatal for bundled plugins — fall back to bundled defaults instead of fail-closing desktop feature availability (which silently kills Computer Use).
3. Distinguish "feature flags failed to load" from "not installed" in the UI instead of the generic "Computer Use plugins unavailable".

Happy to provide full redacted codex-desktop-*.log files.

I hit the same Settings symptom on a newer Windows Desktop build and was able to recover it locally.

In this case the installed Desktop app bundle did contain openai-bundled entries for browser, chrome, and computer-use, but the user-level Codex config/cache was not using a current usable bundled marketplace/cache. After repairing [marketplaces.openai-bundled] from the installed Desktop app resources, refreshing the user plugin cache from that bundled marketplace, ensuring Computer Use was feature-enabled, and fully restarting the app/app-server, plugin listing showed browser@openai-bundled, chrome@openai-bundled, and computer-use@openai-bundled as installed/enabled. Settings no longer showed Computer Use plugins unavailable.

One additional code-level issue I found while patching locally: the background refresh path for non-curated/bundled plugin caches appeared to schedule refresh using only the explicit roots it was handed. Expanding those roots through the configured local marketplace roots before scheduling refresh fixed this failure mode in my local build. That may explain why reinstall/repair can fail to recover when <CODEX_HOME> retains stale bundled marketplace/cache state.

Omitting machine-specific paths, account details, logs, and feedback identifiers from this public comment.