Skip to content

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

Open
Open
Computer Use native pipe only initializes when the bundled marketplace is (re)written; every normal app restart leaves it "helper paths unavailable"#25665
Labels
appIssues related to the Codex desktop appbugSomething isn't workingcomputer-usewindows-osIssues related to Codex on Windows systems

Description

@raederhans
raederhans
opened on Jun 1, 2026

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.

Activity

  1. raederhans
    added
    appIssues related to the Codex desktop app
    on Jun 1, 2026
  2. github-actions
    added
    bugSomething isn't working
    windows-osIssues related to Codex on Windows systems
    computer-use
    on Jun 1, 2026

  3. github-actions commented on Jun 1, 2026

    @github-actions
    github-actionsBot
    on Jun 1, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  4. yy663 commented on Jun 4, 2026

    @yy663
    yy663
    on Jun 4, 2026 – with ChatGPT Codex Connector

    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
    2. 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
    3. 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.
    4. 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.
    5. 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.
    6. 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.

  5. Statusnone420 commented on Jun 4, 2026

    @Statusnone420
    Statusnone420
    on Jun 4, 2026

    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.

  6. zemeng5208 commented on Aug 12, 2026

    @zemeng5208
    zemeng5208
    on Aug 12, 2026 – with ChatGPT Codex Connector

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingcomputer-usewindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions