Skip to content

[Bug] Windows Codex Desktop: Computer Use plugin missing from UI and native pipe fails with missing-helper-path #25795

Closed as duplicate
Closed as duplicate
[Bug] Windows Codex Desktop: Computer Use plugin missing from UI and native pipe fails with missing-helper-path#25795
Labels
appIssues related to the Codex desktop appbugSomething isn't workingcomputer-useskillsIssues related to skillswindows-osIssues related to Codex on Windows systems

Description

@kyuvkbmgj8696967675-eng
kyuvkbmgj8696967675-eng
opened on Jun 2, 2026

Environment

  • OS: Windows
  • Codex Desktop version: 26.527.7698.0
  • Workspace: D:\Codex
  • Codex app path:
    C:\Program Files\WindowsApps\OpenAI.Codex_26.527.7698.0_x64__2p2nqsd0c76g0\app\Codex.exe

Problem

Computer Use was available yesterday, but today it no longer appears in the Codex plugin UI.

The local config still contains:

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

However, the current bundled marketplace cache only contains chrome, and computer-use is not visible in the plugin list.

Observed logs

computer-use native pipe startup failed
errorMessage="Windows Computer Use helper paths are unavailable"
reason=missing-helper-path

Downstream error when trying to use Computer Use:

Computer Use native pipe path is unavailable

Additional details

The Computer Use files appear to exist inside the installed Codex package, including:

C:\Program Files\WindowsApps\OpenAI.Codex_26.527.7698.0_x64__2p2nqsd0c76g0\app\resources\plugins\openai-bundled\plugins\computer-use\node_modules\@oai\sky\bin\windows\codex-computer-use.exe

But Codex Desktop does not register Computer Use in the UI and does not create/pass SKY_CUA_NATIVE_PIPE_DIRECTORY to the tool session.

Tried

  • Restarted Codex many times
  • Reinstalled Codex Desktop
  • Renamed/rebuilt bundled plugin cache under ~/.codex
  • Checked plugin cache and logs

Expected

Computer Use should appear in the plugin UI and native pipe should start successfully.

Actual

Computer Use is missing from the UI and native pipe startup fails with missing-helper-path.

Activity

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

  2. github-actions commented on Jun 2, 2026

    @github-actions
    github-actionsbot
    on Jun 2, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. kk9482677-rgb commented on Jun 2, 2026

    @kk9482677-rgb
    kk9482677-rgb
    on Jun 2, 2026 – with ChatGPT Codex Connector

    Confirming the same Computer Use failure on another Windows installation with the same Codex Desktop build.

    Environment

    • Codex Windows app: 26.527.7698.0
    • Bundled/local CLI: 0.136.0-alpha.2
    • OS: Windows 11 Core x64, version 10.0.26200
    • Locale: zh-TW
    • MSIX package status: Ok

    Observed behavior

    The bundled Computer Use plugin files and native helper binary exist inside the installed package, including the Windows codex-computer-use.exe helper. However, Codex Desktop repeatedly fails to initialize the native pipe.

    Redacted app log excerpt:

    [computer-use-native-pipe] computer-use notify config ensure finished platform=win32 reason=missing-helper-path status=skipped
[computer-use-native-pipe] computer-use native pipe startup failed errorMessage="Windows Computer Use helper paths are unavailable" platform=win32

    The same failure repeats during the app session. Windows app repair and uninstall/reinstall did not resolve it.

    Expected behavior: when the bundled helper exists, Codex Desktop should resolve its stable helper path and initialize the native Computer Use pipe.

  4. yunyunFlow commented on Jun 3, 2026

    @yunyunFlow
    yunyunFlow
    on Jun 3, 2026 – with ChatGPT Codex Connector

    Additional current-build evidence from Windows + WSL mode, sanitized. This may be the same class of Computer Use / Chrome availability regression, but on a newer package than the original report.

    Environment:

    Codex Desktop Windows package: OpenAI.Codex_26.601.2237.0_x64__2p2nqsd0c76g0
Active WSL CLI: codex-cli 0.136.0-alpha.2
OS: Windows 11 + WSL2 Ubuntu 24.04.4 LTS
Kernel: 6.6.114.1-microsoft-standard-WSL2
Chrome executable: C:\Program Files\Google\Chrome\Application\chrome.exe
Chrome version: 148.0.7778.179
Mode: runCodexInWindowsSubsystemForLinux = true, integratedTerminalShell = "wsl"

    Observed user-visible behavior:

    • Settings > Computer Control / Computer Use shows controls greyed out with text equivalent to: "disabled by your organization, or unavailable in your region".
    • User is on a personal account and physically located in France.
    • Chrome/Browser/Computer Use cannot control Chrome.

    Read-only evidence collected:

    codex features list:
browser_use          stable true
browser_use_external stable true
computer_use         stable true
in_app_browser       stable true
apps                 stable true
plugins              stable true

~/.codex/computer-use/config.json exists and contains only UI strings/theme-like settings.
Windows process list shows both chrome.exe and Codex.exe processes running.
Chrome user-data root exists under the Windows user profile.

    Plugin/config observations:

    codex mcp list: no MCP servers configured
codex plugin list: current openai-bundled marketplace showed latex only in CLI output; current user config did not list chrome@openai-bundled or computer-use@openai-bundled as enabled plugins.
Older cache entries exist for openai-bundled/browser 26.519.41501, suggesting prior bundled browser/chrome-related artifacts existed, but the current visible plugin marketplace/config state does not expose an enabled Chrome/Computer Use plugin path from the WSL CLI.

    Interpretation:

    On this current Windows + WSL build, feature flags say browser/computer use are enabled, Chrome is installed/running, and Codex is running, but the Desktop UI still gates Computer Control and the CLI plugin surface does not expose a usable Chrome/Computer Use plugin. This looks like a product gating/availability or plugin registration/bridge problem rather than Chrome not being installed or WSL being unable to see Windows processes.

  5. jackwu-iii commented on Jun 5, 2026

    @jackwu-iii
    jackwu-iii
    on Jun 5, 2026

    Observed user-visible behavior:

    • Settings > Computer Control / Computer Use shows controls greyed out with text equivalent to: "disabled by your organization, or unavailable in your region".
    • User is on a personal account and physically located in France.
    • Chrome/Browser/Computer Use cannot control Chrome.
    1. I'm in Taiwan, my pc update to 0.137.0, computer use broken. My pc is not in any organiztion.
    2. My nb not update to 0.137.0, keep on 0.136.0, computer use is properly work.

    So, It's not region fails. Also no relation with region or organization.

    I think is App or Plugin support version validation fail.

  6. etraut-openai
    closed this as a duplicateof Windows Computer Use native pipe fails: helper paths unavailable on 26.527.31326 #25571 on Aug 6, 2026

  7. zemeng5208 commented on Aug 12, 2026

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

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

    One of the reproductions in this thread is a good match for the local helper-resolution layer WinBridge is intended to diagnose: on Windows 11 / zh-TW, the current MSIX package is healthy and the bundled Computer Use files, including codex-computer-use.exe, exist in the installed package, but Desktop repeatedly reports reason=missing-helper-path / Windows Computer Use helper paths are unavailable. Windows App Repair and reinstall do not repair that user/runtime state.

    WinBridge v3.1.1 resolves the currently installed OpenAI.Codex AppX first, reads the bundled plugin/CUA manifests, verifies the official runtime/helper resources, and compares them with the generated marketplace, versioned Computer Use cache, CUA/Node REPL runtime, CODEX_CLI_PATH, NODE_REPL_NODE_PATH, and helper paths actually configured in the user profile. When those local layers are stale, missing, or split across versions, it can rebuild the user-owned state through verified staging, SHA-256 checks, backups and rollback.

    That is different from the other reports in this thread where the UI is intentionally gated by WSL mode, organization/region availability, or where the helper/runtime is healthy but the native-pipe capability is never injected into the active thread. WinBridge cannot and should not bypass those product/runtime gates; it should report them as upstream once the local state validates.

    It does not modify WindowsApps ownership/ACLs, decrypt the Store package, or patch OpenAI binaries.

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-useskillsIssues related to skillswindows-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