›_ Codex Issues
Codex Issues / #25665

Computer Use native pipe only initializes when the bundled marketplace is (re)written; every normal app restart leaves it "helper paths unavailable"

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

What version of the Codex App are you using (From “About Codex” dialog)?

OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0

What subscription do you have?

GPT PRO

What platform is your computer?

Windows 11 Pro, build 10.0.26200

What issue are you seeing?

On Windows, the Computer Use native pipe fails to start on a normal app launch with Windows Computer Use helper paths are unavailable. It only reaches a working ("ready") state on a launch that happens to rewrite the bundled-plugins marketplace (e.g. right after a repair/rebuild). On the next ordinary restart it breaks again. The helper binary itself is present the whole time.

What steps can reproduce the bug?

Launch that rebuilt the marketplace → works:

computer-use notify config ensure finished status=already-present (or status=repaired)
computer-use native pipe startup ready pipePath=\\.\pipe\codex-computer-use-...
... (then later it can flip:)
computer-use native pipe helper paths changed
computer-use notify config ensure finished reason=missing-helper-path status=skipped
computer-use native pipe startup failed errorMessage="Windows Computer Use helper paths are unavailable"
Ordinary restart (no marketplace rewrite) → fails repeatedly:

computer-use notify config ensure finished reason=missing-helper-path status=skipped
computer-use native pipe startup failed errorMessage="Windows Computer Use helper paths are unavailable"
(repeats every few seconds)

What is the expected behavior?

I should be able to see the page of computer use plugin in Codex app working normal.

Additional information

The Computer Use helper-path resolution only succeeds while/just after the bundled marketplace is being written for that session; on a normal launch the resolver returns missing-helper-path even though the helper exists in the plugin cache. Looks like the resolved helper path is tied to a transient marketplace-write path rather than the stable plugin-cache install location.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 2 months ago

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

  • #25571
  • #25507
  • #25391
  • #25512

Powered by Codex Action

yy663 · 2 months ago

I hit what looks like the same failure on Windows and was able to recover it by repairing the bundled marketplace/cache paths manually.

Environment:

  • Codex Desktop package: OpenAI.Codex_26.601.2237.0_x64__2p2nqsd0c76g0
  • Codex CLI: codex-cli 0.136.0-alpha.2
  • Windows, user-level Codex config under %USERPROFILE%\.codex

Broken state observed:

  • config.toml had marketplaces.openai-bundled.source pointing at the transient path:
  • \\?\%USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled
  • That transient marketplace was incomplete; in my case it only had a partial plugins\chrome subtree and was missing .agents\plugins\marketplace.json plus other bundled plugin directories.
  • The stable bundled cache directory was also incomplete/empty for the affected plugins.
  • codex:// under HKCU\Software\Classes\codex only had the bare URL Protocol entry, while the generated AppX... handler had the AppX DelegateExecute open command.
  • Computer Use failed before enumeration with Computer Use native pipe path is unavailable / helper paths unavailable.

Manual recovery that worked:

  1. Copied the full bundled marketplace from the installed package:
  • from C:\Program Files\WindowsApps\OpenAI.Codex_26.601.2237.0_x64__2p2nqsd0c76g0\app\resources\plugins\openai-bundled
  • to %USERPROFILE%\.codex\plugins\cache\openai-bundled\marketplace-source
  1. Updated %USERPROFILE%\.codex\config.toml to point marketplaces.openai-bundled.source at:
  • \\?\%USERPROFILE%\.codex\plugins\cache\openai-bundled\marketplace-source
  • saved as UTF-8 without BOM
  1. Populated stable plugin cache entries for browser, chrome, and computer-use from the installed package. The manifest version in this build is 26.601.21317, so latest points to that version.
  2. Also filled the old transient %USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled marketplace with .agents\plugins\marketplace.json and the bundled plugin directories, so any stale reader still sees a complete marketplace.
  3. Repaired HKCU\Software\Classes\codex by copying the AppX handler shape from HKCU\Software\Classes\AppXybfp6cjpb1wf0pftw0fd4bz59gzn1401, preserving URL Protocol and adding Shell\open\command\DelegateExecute.
  4. Fully restarted Codex Desktop.

Post-restart validation:

Using the actual local CLI binary under %LOCALAPPDATA%\OpenAI\Codex\bin\...\codex.exe:

MARKETPLACE             ROOT
openai-bundled          %USERPROFILE%\.codex\plugins\cache\openai-bundled\marketplace-source
chrome@openai-bundled        installed, enabled  26.601.21317
computer-use@openai-bundled  installed, enabled  26.601.21317

Runtime validation:

  • Chrome backend connected as extension.
  • Computer Use list_windows succeeded and returned 8 windows.
  • After filtering out my own diagnostic commands/messages from the local log DB, recent matches for both of these were 0:
  • bundled_plugins_marketplace_resolve_failed
  • Windows Computer Use helper paths are unavailable

One related observation: running plain codex from PowerShell still resolved to the protected WindowsApps app\resources\codex.exe and failed with Access is denied; the working CLI binary was the one under %LOCALAPPDATA%\OpenAI\Codex\bin\.... That may be separate from this issue, but it made CLI validation confusing.

This seems to support the theory that helper-path / bundled-plugin resolution can get tied to a transient or incomplete bundled marketplace location instead of the stable plugin cache, and that the app should either persist the bundled marketplace source to a stable cache path or make the transient bundled marketplace rewrite atomic/complete before consumers resolve helper paths.

Statusnone420 · 2 months ago

Adding another Windows 26.601 data point that supports the link between bundled marketplace materialization and Computer Use helper availability.

Environment:

Codex Desktop: OpenAI.Codex_26.601.2237.0_x64__2p2nqsd0c76g0
Desktop/internal CLI: codex-cli 0.136.0-alpha.2
Computer Use plugin: computer-use@openai-bundled 26.601.21317
openai-bundled source: %USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled

Recent Desktop logs from the affected machine included repeated native-pipe startup failures:

[computer-use-native-pipe] computer-use native pipe startup failed
errorMessage="Windows Computer Use helper paths are unavailable"

The same machine later recovered once the Desktop-owned openai-bundled marketplace under .codex\.tmp\bundled-marketplaces\openai-bundled was complete again, including:

.codex\.tmp\bundled-marketplaces\openai-bundled\.agents\plugins\marketplace.json
.codex\.tmp\bundled-marketplaces\openai-bundled\plugins\computer-use\.codex-plugin\plugin.json

Validation after recovery, from a live Codex Desktop session using the Computer Use plugin runtime:

list_apps: ok, appCount=40, runningApps=5, targetableWindows=5
list_windows: ok, windowCount=5

I also performed a visible smoke test: Computer Use opened/targeted Notepad and typed a short message into a fresh tab. That confirms the helper was actually callable after the bundled marketplace/helper metadata was present, not just listed as installed.

This suggests the failure is not simply that the helper executable is missing. It looks like the Desktop host can stop publishing/resolving the helper path when the generated openai-bundled marketplace is incomplete or stale. A useful diagnostic would be for Settings or doctor to show which exact marketplace manifest/plugin manifest was used to derive the Computer Use helper path, and whether that manifest was missing or rejected.

zemeng5208 · 16 days ago

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

This helper-path lifecycle is a good match for the local consistency problem the project targets. v3.1.1 checks the current AppX package against the active openai-bundled marketplace, versioned Browser/Chrome/Computer Use caches, latest targets, CUA runtime/helper paths, app-server files, and Native Host state. If those layers are already healthy it skips repair; if they diverge, recovery is staged/verified before switching active state, with rollback/backups available.

The key symptom here — helper resolution working immediately after a marketplace rewrite but failing on the next ordinary launch — is exactly why I avoid treating “plugin installed/enabled” as sufficient. A recovery/diagnostic tool needs to compare the source generation -> active marketplace -> versioned cache/latest -> runtime/helper paths as one chain and identify the first divergent layer.

WinBridge may help when the cause is an incomplete/transient marketplace, stale cache/latest, or stale helper/runtime paths. It cannot fix an upstream case where all local layers are current and the Desktop host simply fails to inject/start the native pipe; in that case it should report the local state as healthy and stop rather than repeatedly rewriting it.