›_ Codex Issues
Codex Issues / #26929

Windows Codex Desktop: Computer Use / Chrome tools missing or unstable after intermittent helper-path failures, even when native pipe later starts ready

Open 💬 6 comments Opened Jun 8, 2026 by 1341699206
💡 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)?

26.602.40724

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64 Additional Windows version information: Windows 11 Pro Version 25H2 OS build 26200.8457

What issue are you seeing?

What version of the Codex App are you using?

26.602.40724

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Windows 11 Pro
Version 25H2
OS build 26200.8457

What issue are you seeing?

I am seeing an issue on Windows Codex Desktop where Computer Use / Chrome related tools are missing, unavailable, or unstable.

This does not look like a normal project configuration problem. The issue appears related to Windows Computer Use helper/native-pipe initialization and/or runtime tool discovery.

Earlier logs showed repeated Computer Use native pipe startup failures:

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

Later, after restarting/retrying, the logs started showing Computer Use native pipe startup as ready:

info [computer-use-native-pipe] computer-use native pipe startup ready pipePath=\\.\pipe\codex-computer-use-... platform=win32

Browser Use native pipe also starts:

info [browser-use-native-pipe-server] browser-use native pipe listening pipePath=\\.\pipe\codex-browser-use-...

However, Computer Use / Chrome tool availability remains unreliable or not exposed in the Codex session/tool store.

So the problem seems intermittent or session-state dependent: the native pipe/helper may fail at first with helper paths are unavailable, then later report startup ready, but the Computer Use / Chrome tools are still not reliably exposed or usable.

What steps can reproduce the bug?

  1. Install or update Codex Desktop on Windows 11.
  2. Sign in with a ChatGPT Plus account.
  3. Open Codex Desktop.
  4. Try to use Computer Use / Chrome related tools.
  5. Observe that the Computer Use / Chrome tools are missing, unavailable, or not exposed in the tool store/session.
  6. Check Codex desktop logs.
  7. Logs may show earlier repeated failures:
Windows Computer Use helper paths are unavailable
  1. After restarting/retrying, logs may later show:
computer-use native pipe startup ready
  1. Despite the native pipe later being ready, Computer Use / Chrome tools are still not reliably exposed or usable.

What is the expected behavior?

If Windows Computer Use is supported for the current account/region/platform, Codex Desktop should reliably expose the Computer Use / Chrome tools and allow Computer Use to control Windows desktop apps.

If Computer Use is not available, the app should clearly distinguish between:

  • account/region/feature-flag not eligible;
  • plugin marketplace/cache issue;
  • helper path missing;
  • native pipe startup failure;
  • native pipe ready but runtime/tool discovery not exposing Computer Use;
  • sandbox/ACL setup failure.

The current behavior makes it difficult to tell whether the failure is caused by plugin discovery, feature availability, native helper startup, or session/runtime tool provisioning.

Additional information

Relevant log excerpts, with username redacted:

info [bundled-plugins] bundled_plugins_reconcile_skipped_features_unavailable reason=focus

info [browser-use-native-pipe-server] browser-use native pipe listening pipePath=\\.\pipe\codex-browser-use-...

warning [computer-use-native-pipe] computer-use native pipe startup failed errorMessage="Windows Computer Use helper paths are unavailable" errorName=Error platform=win32

info [computer-use-native-pipe] computer-use native pipe startup ready pipePath=\\.\pipe\codex-computer-use-... platform=win32

This looks related to other Windows Computer Use issues involving:

  • Computer Use / Chrome tools missing from the tool store;
  • Computer Use plugins unavailable;
  • Windows Computer Use helper paths unavailable;
  • native pipe startup instability;
  • Computer Use runtime/tool discovery not exposing the required tools.

The issue appears intermittent: earlier logs repeatedly show helper-path failures, while later logs show native pipe startup ready, but Computer Use / Chrome tool availability remains unreliable.

What steps can reproduce the bug?

Install or update Codex Desktop on Windows 11.
Sign in with a ChatGPT Plus account.
Open Codex Desktop.
Try to use Computer Use / Chrome related tools.
Observe that Computer Use / Chrome tools are missing, unavailable, or not exposed in the session/tool store.
Check Codex desktop logs under:
%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs
Logs may show earlier repeated failures:
Windows Computer Use helper paths are unavailable
After restarting/retrying, logs may later show:
computer-use native pipe startup ready
Despite the native pipe later being ready, Computer Use / Chrome tools are still not reliably exposed or usable.

What is the expected behavior?

If Windows Computer Use is supported for the current account, region, platform, and app version, Codex Desktop should reliably expose the Computer Use / Chrome tools and allow Computer Use to control Windows desktop apps.

If Computer Use is unavailable, the app should clearly distinguish between:

account / region / feature-flag not eligible;
plugin marketplace or bundled cache issue;
helper path missing;
native pipe startup failure;
native pipe ready but runtime/tool discovery not exposing Computer Use;
sandbox / ACL setup failure.

The current behavior makes it difficult to tell whether the failure is caused by plugin discovery, feature availability, native helper startup, or session/runtime tool provisioning.

Additional information

Current app version:

Codex App: 26.602.40724

Current OS:

Windows 11 Pro
Version 25H2
OS build 26200.8457
x64

Relevant log excerpts, with username redacted:

info [bundled-plugins] bundled_plugins_reconcile_skipped_features_unavailable reason=focus

info [browser-use-native-pipe-server] browser-use native pipe listening pipePath=\\.\pipe\codex-browser-use-...

warning [computer-use-native-pipe] computer-use native pipe startup failed errorMessage="Windows Computer Use helper paths are unavailable" errorName=Error platform=win32

info [computer-use-native-pipe] computer-use native pipe startup ready pipePath=\\.\pipe\codex-computer-use-... platform=win32

One earlier log stack trace referenced the installed WindowsApps package path:

C:\Program Files\WindowsApps\OpenAI.Codex_26.602.3474.0_x64__2p2nqsd0c76g0\app\resources\app.asar\...

The current About Codex dialog now shows:

26.602.40724

This suggests the issue may have started on an earlier 26.602.x build and may still affect the current installation/session state.

This looks related to other Windows Computer Use issues involving:

Computer Use / Chrome tools missing from the tool store;
Computer Use plugins unavailable;
Windows Computer Use helper paths unavailable;
native pipe startup instability;
Computer Use runtime/tool discovery not exposing the required tools.

The issue appears intermittent: earlier logs repeatedly show helper-path failures, while later logs show native pipe startup ready, but Computer Use / Chrome tool availability remains unreliable.

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 2 months ago

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

  • #26133
  • #25665
  • #26785
  • #26692
  • #26528

Powered by Codex Action

1341699206 · 2 months ago

Thanks for the duplicate detection.

This issue looks closely related to #26133, #25665, #26785, #26692, and #26528.

However, I am not sure it is an exact duplicate because my logs show an additional state transition:

  1. Earlier, Computer Use native pipe startup failed with:

Windows Computer Use helper paths are unavailable

  1. Later, after restarting/retrying, the native pipe reported ready:

computer-use native pipe startup ready

  1. But even after the native pipe reported ready, Computer Use / Chrome tools were still not reliably exposed in the Codex runtime/tool store.

So this may be a variant of the existing Windows bundled plugin / Computer Use exposure issue, but with an additional helper-path / native-pipe state transition before the final tool exposure failure.

I will keep this issue open for now in case this extra signal is useful for debugging.

pumalife · 2 months ago

i see the same log lines. though ive already posted in another issue. so im also unsure what specfically is my issue

joshuaflower · 2 months ago

I can confirm this is still reproducible on a newer Windows Codex Desktop build.

Environment:

  • Codex Desktop: 26.602.71036, released Jun 8, 2026
  • Subscription: Codex 20x / highest plan
  • Platform: Microsoft Windows NT 10.0.26200.0 x64

Observed:

  • Settings > Uso do computador shows: “Plugins de uso do computador indisponíveis”.
  • “Computer Use: Computer Use” appears under Skills and is enabled.
  • Searching Plugins for “computer” does not show a Computer Use plugin.
  • Browser and Chrome automation work in the same installation.
  • Computer Use fails before app listing / list_apps() / Windows control with:
Computer Use native pipe path is unavailable

Additional local check from the session:

hasNativePipe: false
SKY_CUA_NATIVE_PIPE_DIRECTORY: null/missing

So this does not look like a normal project config issue. The Computer Use skill is visible/enabled, but the native pipe/runtime metadata needed by the skill is not exposed. I can provide private logs or a /feedback session ID through the private feedback channel if needed.

quixoticcipher-design · 26 days ago

Adding another Windows reproduction with the same tool-provisioning failure.

Environment:

  • Codex Desktop: 26.727.6591.0
  • Computer Use bundled plugin: 26.715.52143
  • Windows native workspace (not WSL)

Observed state:

  • Computer Use is enabled in Plugins.
  • @Computer / @电脑 is available and can be attached to the prompt.
  • The bundled plugin, computer-use-client.mjs, node_repl.exe, Sky runtime, and Chrome native-host configuration all exist locally.
  • No managed requirements.toml policy disables Computer Use.
  • However, the task tool surface does not expose mcp__node_repl__js (or another Node REPL execution tool), so the documented Computer Use bootstrap cannot run.
  • Chrome control is affected by the same missing execution bridge.
  • Repeated app restarts, new tasks, and toggling/re-enabling the plugins do not change the result.

This looks like the "plugin visible and selectable, but runtime/tool discovery never injects the privileged Node REPL/Computer Use bridge" branch described in this issue, rather than a missing plugin installation.

zemeng5208 · 16 days ago

Disclosure: I’m the maintainer of WinBridge Recovery, an independent Windows Codex Desktop recovery project.

This report spans two possible layers, and the distinction matters. The earlier Windows Computer Use helper paths are unavailable state is something the tool can diagnose against the installed package/runtime/cache: it checks for post-update drift among the bundled marketplace, plugin versions/latest pointers, cua_node, and local host/runtime registration, with backup/rollback before repair.

The later state in this issue — native pipes report ready but tools are still not exposed in the active session — may be a separate session/tool-discovery problem. WinBridge Recovery should not be expected to fix that if the local files and registrations already validate correctly.

So for anyone hitting this issue, I’d use the tool mainly to answer and repair the local-state half first. If it reports a consistent runtime/cache/native-host state and the pipe is ready but the tools remain missing, that is useful evidence that the remaining failure is upstream/session-side rather than another cache reinstall problem.