Skip to content

Windows Computer Use Skill installed but native connection unavailable after update 26.5.27.31326 #25512

Open
Open
Windows Computer Use Skill installed but native connection unavailable after update 26.5.27.31326#25512
Labels
appIssues related to the Codex desktop appbugSomething isn't workingcomputer-usewindows-osIssues related to Codex on Windows systems

Description

@chee7n2023-ux
chee7n2023-ux
opened on Jun 1, 2026

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

26.5.27.31326

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Windows 11 x64

What issue are you seeing?

Computer Use Skill is installed and enabled.

Environment:

  • Taiwan
  • ChatGPT Plus
  • Windows 11
  • Codex 26.5.27.31326

Problem:

Computer Use appears in the Skills marketplace and is enabled.

However every Computer Use action fails.

Example:

Prompt:
Open Notepad

Response:
"I tried to connect to Windows through the Computer Use plugin, but it reported that the native Computer Use connection is unavailable for this turn."

Other errors observed:

  • native pipe path is unavailable
  • Computer Use connection is unavailable

Troubleshooting already performed:

  • Reinstalled Codex multiple times
  • Restarted Windows
  • Verified Computer Use Skill is enabled
  • Verified account is in Taiwan and on ChatGPT Plus
  • Verified Codex CLI works normally

Additional findings:

Computer Use Skill exists and can be invoked, but the Windows host never connects.

Under:

%LOCALAPPDATA%\OpenAI

only the following folders exist:

  • Codex
  • extension

No Computer Use host folders, services, or processes appear.

The issue started after updating to version 26.5.27.31326.

Computer Use previously worked before the update.

What steps can reproduce the bug?

  1. Open Codex Desktop App on Windows 11.

  2. Verify that "Computer Use: Computer Use Skill" is installed and enabled.

  3. Start a new chat.

  4. Send a simple Computer Use request such as:

    Open Notepad

  5. Codex invokes the Computer Use skill.

  6. The request immediately fails with:

    "I tried to connect to Windows through the Computer Use plugin, but it reported that the native Computer Use connection is unavailable for this turn."

  7. The issue occurs every time and is reproducible 100% of the time.

What is the expected behavior?

When a Computer Use request is issued, Codex should connect to the local Windows Computer Use host and perform the requested action.

For example:

Prompt:
Open Notepad

Expected result:
Windows Notepad opens successfully.

Additional information

Image Image

Activity

  1. chee7n2023-ux
    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. tangzfc-tt commented on Jul 15, 2026

    @tangzfc-tt
    tangzfc-tt
    on Jul 15, 2026 – with ChatGPT Codex Connector

    Additional reproducible case on the current Windows build.

    Environment:

    • Codex Desktop: 26.707.9981.0 (Microsoft Store/MSIX)
    • Codex CLI: 0.144.2
    • OS: Windows 11 Home, 10.0.26200, x64
    • Computer Use plugin: 26.707.72221, installed and enabled
    • Computer Use feature flag: true
    • Trusted runtime: cua-node 0.0.4 / 20260713191736-ad8b1874340f-pr-1124580
    • Node REPL runtime: 20260713.2
    • Native Windows workspace (not WSL)

    Observed behavior:

    • New Codex Desktop threads load the Computer Use skill, but expose no Node REPL / trusted Windows execution entry point.
    • No mcp__node_repl__js, node_repl js, js, or equivalent Computer Use execution tool is present in the thread tool set.
    • A prompt that explicitly invokes computer-use@openai-bundled to list open applications cannot reach list_apps().
    • Reproduces across multiple new threads after fully quitting and restarting Codex.
    • Example affected thread/task ID: 019f6674-b368-7a43-8574-1a66e75c5c7c

    Additional local evidence:

    • The app updated while the per-user trusted runtime cache remained on an older June runtime (cua-node 0.0.1 / Node REPL 20260605.1).
    • Copying the current bundled runtime out of the WindowsApps package with robocopy failed with Windows error 6000: "The specified file could not be encrypted." This matches the EFS/Application Protected packaging symptoms reported in [Windows] Bundled plugins (Computer Use, Browser, Chrome, LaTeX) unavailable — copyfile fails on EFS-encrypted WindowsApps files #25220.
    • A byte-for-byte copy using System.IO.File.ReadAllBytes/WriteAllBytes succeeded. The cached node_repl.exe SHA-256 then matched the current app package exactly.
    • Browser, Chrome, and Computer Use plugins were synchronized to 26.707.72221 and reinstalled.
    • codex doctor and strict config validation both report OK.
    • Despite the synchronized runtime, matching hashes, enabled flags, app restart, and new threads, the trusted Windows/Node REPL entry point is still not injected.

    This suggests two layers:

    1. WindowsApps EFS prevents normal runtime/plugin reconciliation on affected machines.
    2. Even after repairing the local runtime/cache mismatch, Codex Desktop still does not provision the trusted execution bridge into the thread.

    A normal manually configured MCP server is not an equivalent workaround because it cannot reproduce the trusted native pipe and Codex turn/session metadata. Please investigate the Desktop tool-injection/host-service provisioning path for current 26.707 Windows builds.

  5. mshirley1964 commented on Aug 9, 2026

    @mshirley1964
    mshirley1964
    on Aug 9, 2026 – with ChatGPT Codex Connector

    I can reproduce the same underlying failure on a newer Windows desktop build.

    Environment

    • ChatGPT Plus
    • ChatGPT/Codex desktop app version 26.803.41515 (released August 6, 2026)
    • Computer Use plugin enabled

    Observed behavior

    • The Computer Use plugin page shows only Skills 1 → Computer Use.
    • The expected MCP servers 1 → Computer-use section is completely absent.
    • In a new, active Codex chat, a simple request to open Windows Calculator reports that Computer Use controls are unavailable in the session.
    • Chrome control is installed and connected, so the failure appears specific to the local native Computer Use server/helper.

    Troubleshooting completed

    • Reinstalled the Computer Use plugin multiple times.
    • Confirmed Windows Defender Protection History shows no blocked or quarantined items.
    • Confirmed Computer Use is enabled and “Any App” is allowed.
    • Ran Windows Repair on the current ChatGPT desktop app; the MCP server remained missing.
    • Did not enable Full Access or use Windows Reset.

    Diagnostic feedback ID from the affected Codex session: 919fe425-0f76-7792-b011-8fd3bef5c4c9

    This suggests the native Computer Use server/helper is not being provisioned or registered at all, rather than starting and then failing to connect.

  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/diagnostic tool for Codex Desktop local plugin/runtime state: https://github.com/zemeng5208/winbridge-recovery

    The newer reports here are useful because they show two separate layers that should not be conflated. On affected machines, the Store update can leave the user-side CUA/Node REPL runtime and bundled plugin cache behind the current package, and Application Protected resources can block normal reconciliation. That local package -> runtime/cache mismatch is within WinBridge's scope: it checks package/plugin/runtime versions and hashes, reconstructs user-owned official-resource copies through verified staging, and validates helper paths/state afterward.

    However, the 26.707 report also shows an important boundary: after the runtime was synchronized byte-for-byte and hashes matched, the trusted Node REPL/Computer Use execution bridge still was not injected. WinBridge should not claim to repair that host/tool-injection layer. Likewise, if 26.803 has complete current runtime/helper files but Desktop simply never provisions the native server into the session, that is an upstream Desktop runtime issue.

    So for users here the tool may help answer and recover the first question — “are my marketplace/cache/runtime/helper files actually current and consistent?” — while deliberately stopping if those layers are healthy and the failure is the trusted bridge itself. It does not bypass feature gates, sandbox/trust policy, or patch the app package.

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