Windows Computer Use native pipe fails: helper paths unavailable on 26.527.31326

Summary

On Windows, Computer Use / Browser Use appears to be enabled by the runtime availability gate, but the native Computer Use pipe fails to start repeatedly with:

Windows Computer Use helper paths are unavailable

This does not look like the statsig-disabled / entitlement-not-exposed case. The latest logs show available=true reason=available, followed by native helper path failures.

Environment

OS: Windows 11 x64
Subscription: ChatGPT Plus
Codex Windows Store package: OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0
Codex desktop release from logs: 26.527.31326
Shell/runtime in this Codex session: Windows PowerShell
C:\Users\<user>\.codex\config.toml does not contain runCodexInWindowsSubsystemForLinux = true

Observed log evidence

Latest relevant desktop log under:

%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs\2026\06\01\...

shows Browser/Computer Use availability resolving as available:

2026-06-01T07:39:27.963Z info [electron-message-handler] browser_use_availability_resolved available=true browserPane=true platform=Windows reason=available release=26.527.31326

Immediately afterward, native Computer Use pipe startup fails:

2026-06-01T07:39:35.374Z warning [computer-use-native-pipe] computer-use native pipe startup failed errorMessage="Windows Computer Use helper paths are unavailable" platform=win32

The same failure repeats across multiple attempts in the same log:

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

Browser-use native pipe does start:

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

Local package evidence

The installed Windows Store package exists at a WindowsApps package path similar to:

...\OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0\app\resources\plugins\openai-bundled\plugins\computer-use

The app also has:

...\app\resources\native\windows-updater.node

but I could not identify a working Windows Computer Use helper path from the runtime behavior.

Expected behavior

When Computer Use availability resolves as:

available=true reason=available platform=Windows

the Windows native Computer Use helper/pipe should start successfully, and Computer Use actions should be able to connect to the local Windows host.

Actual behavior

Computer Use actions fail because the native Computer Use connection is unavailable for the turn. Logs show repeated native pipe startup failure due to missing/unavailable Windows Computer Use helper paths.

Why this seems distinct from entitlement gating

This machine currently does not show:

reason=statsig-disabled

Instead, it shows:

available=true reason=available

then fails at the native helper/pipe layer.

This looks closer to #25512 than #25253, and adjacent to the helper-path symptoms discussed in #25301, except this setup does not appear to be configured to run Codex in WSL.

Troubleshooting already done

Confirmed GitHub/open issue reports with similar Windows native connection symptoms.
Checked config.toml for WSL-backed app-server settings; did not find runCodexInWindowsSubsystemForLinux = true.
Checked current desktop logs and confirmed the failure is reproducible across repeated attempts.
Earlier reinstall/relogin/device-code auth checks did not resolve the issue.

Request

Please investigate Windows native Computer Use helper packaging/path resolution for Codex 26.527.31326, especially the case where availability resolves as available=true, but the Computer Use native pipe fails with Windows Computer Use helper paths are unavailable.

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

Windows Computer Use Skill installed but native connection unavailable after update 26.5.27.31326 #25512
Windows Computer Use unavailable: nativePipe missing and SKY_CUA_NATIVE_PIPE_DIRECTORY not injected #25507
Windows Computer Use plugin fails to bootstrap: native pipe path is unavailable #25391

Powered by Codex Action

Additional local evidence from read-only diagnostics:

The plugin client expects the native pipe path from:

globalThis.nodeRepl?.env?.SKY_CUA_NATIVE_PIPE_DIRECTORY

If that value is missing, scripts/computer-use-client.mjs throws:

Computer Use native pipe path is unavailable

Desktop logs show an even earlier failure before the plugin client can connect:

[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 expected helper binary does exist inside the installed bundled plugin:

...\plugins\computer-use\node_modules\@oai\sky\bin\windows\codex-computer-use.exe

with size about 1,683,456 bytes.

The package code appears to default to this helper path from @oai/sky:

bin\windows\codex-computer-use.exe

So this no longer looks like a missing installed plugin file. It looks more like the desktop/native-pipe startup code is failing to resolve or pass through the helper path even though the helper binary is present in the bundled plugin tree.

More local diagnostics suggest this may be related to WindowsApps package relocation / protected package files on this machine:

The running process path is under:

C:\Program Files\WindowsApps\OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0\app\Codex.exe

But that package path is a junction to:

D:\WindowsApps\OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0

The actual package files under D:\WindowsApps\... have Encrypted / Application Protected attributes according to cipher /c. For example:

E codex.exe
  Compatibility Level:
    Application Protected

E node.exe
  Compatibility Level:
    Application Protected

E codex-computer-use.exe
  Compatibility Level:
    Application Protected

Attempting to run the helper directly for a minimal smoke test fails with Windows Access is denied:

Program 'codex-computer-use.exe' failed to run ... Access is denied.

Desktop logs also show broader bundled executable relocation failures, not only Computer Use:

bundled_executable_relocation_failed ... executableName=codex.exe operation=copy_file ... sourcePath="C:\Program Files\WindowsApps\...\app\resources\codex.exe"
bundled_executable_relocation_failed ... executableName=node.exe operation=copy_file ... sourcePath="C:\Program Files\WindowsApps\...\app\resources\node.exe"
bundled_executable_relocation_failed ... executableName=node_repl.exe operation=copy_file ... sourcePath="C:\Program Files\WindowsApps\...\app\resources\node_repl.exe"
bundled_executable_relocation_failed ... executableName=rg.exe operation=copy_file ... sourcePath="C:\Program Files\WindowsApps\...\app\resources\rg.exe"

The target cache directory exists but is empty:

C:\Users\<user>\AppData\Local\OpenAI\Codex\bin

So a plausible local trigger is: Codex is installed as a WindowsApps package whose real storage target is D:\WindowsApps; bundled executables are application-protected/encrypted and relocation from the WindowsApps package to %LOCALAPPDATA%\OpenAI\Codex\bin fails. Computer Use then reports missing-helper-path / Windows Computer Use helper paths are unavailable.

A likely workaround to test would be installing/moving Codex onto the normal system WindowsApps location on C: rather than the redirected/junctioned D:\WindowsApps package location.

I can reproduce a very similar failure on a freshly reinstalled Codex Desktop for Windows, but with a newer Store package/version.

Environment:

Windows, PowerShell session
Codex Store package: OpenAI.Codex_26.602.3474.0_x64__2p2nqsd0c76g0
Codex version from AppX: 26.602.3474.0
Computer Use plugin cache/version present: computer-use/26.602.30954
Browser Use appears to be available; multiple codex-browser-use... named pipes exist
Computer Use named pipe is missing

Observed behavior:

The bundled Computer Use client exists at:
<USER>\.codex\plugins\cache\openai-bundled\computer-use\26.602.30954\scripts\computer-use-client.mjs
Running the official bootstrap/reset flow still fails before sky.list_apps() returns.
globalThis.nodeRepl?.env is {}
globalThis.nodeRepl?.nativePipe is missing/undefined
Windows named pipe enumeration shows codex-browser-use... and codex-ipc, but no Computer Use / sky pipe.

Exact error:

Computer Use native pipe is unavailable: Error: failed to connect native pipe: 지정된 파일을 찾을 수 없습니다. (os error 2)

Troubleshooting already tried:

Reset the JS execution session and retried bootstrap
Restarted Codex
Restarted Windows
Toggled browser access permission
Reinstalled Codex Desktop
Ran Reset-AppxPackage / AppX re-register repair; package status returned to Ok

Result after reinstall/repair is unchanged: Browser Use pipe exists, but Computer Use native pipe is not injected into the turn and the Computer Use bootstrap cannot connect.

I can reproduce this on a newer Codex Desktop Windows build after the 26.602 update.

Environment:

OS: Windows 10 Pro x64, Windows 10 22H2 family
Codex Store package/process path: OpenAI.Codex_26.602.4764.0_x64__2p2nqsd0c76g0
Computer Use bundled plugin present: computer-use version 26.602.40724
Runtime bundled marketplace snapshot includes browser, chrome, computer-use, and latex
computer-use@openai-bundled is enabled in config
codex-computer-use.exe exists under the bundled Computer Use plugin tree
%LOCALAPPDATA%\OpenAI\Codex\bin contains node_repl.exe, node.exe, codex.exe, and codex-windows-sandbox-setup.exe

Observed:

Browser native pipes exist, e.g. codex-browser-use... / browser...pipe
No Computer Use / CUA / sky named pipe exists under \\.\pipe\
Node REPL probe:
- hasNativePipe: false
- hasCreateConnection: false
- SKY_CUA_NATIVE_PIPE_DIRECTORY: null
- relevant env keys: []
Official Computer Use bootstrap fails immediately with:

Computer Use native pipe path is unavailable

Already tried:

Restarted Codex Desktop
Rebooted Windows
Updated Codex Desktop
Rebuilt/repaired bundled marketplace/plugin cache
AppX re-register repair completed successfully
Retried the official Computer Use bootstrap after restart/update

Current conclusion:
This does not look like a missing plugin file or missing helper binary. It looks like Codex Desktop is still not creating/publishing/injecting the privileged Computer Use native pipe into this turn, even though the bundled plugin and helper executable are present.

I can reproduce the same Windows Computer Use native pipe failure on a newer Codex Desktop build.

Environment

OS: Windows
Codex Desktop package: OpenAI.Codex_26.602.4764.0_x64__2p2nqsd0c76g0
Codex Desktop version: 26.602.4764.0
AppX package status: 0
Browser Use works and creates a native pipe successfully.
Computer Use plugin and helper executable are present in the installed package.

Verified files

The bundled Computer Use plugin exists:

...\OpenAI.Codex_26.602.4764.0_x64__2p2nqsd0c76g0\app\resources\plugins\openai-bundled\plugins\computer-use\scripts\computer-use-client.mjs

The Computer Use helper executable exists:

...\OpenAI.Codex_26.602.4764.0_x64__2p2nqsd0c76g0\app\resources\plugins\openai-bundled\plugins\computer-use\node_modules\@oai\sky\bin\windows\codex-computer-use.exe

Runtime failure

Computer Use fails during bootstrap before sky.list_apps() can run.

Runtime state before bootstrap:

{
  "hasNodeRepl": true,
  "hasNativePipe": false,
  "hasNativePipeCreateConnection": false,
  "hasEnv": true,
  "skyCuaNativePipeDirectory": null,
  "envKeysContainingPipeOrCua": []
}

Bootstrap error:

Computer Use native pipe path is unavailable

Stack excerpt:

Error: Computer Use native pipe path is unavailable
    at getComputerUsePipePath (...\plugins\openai-bundled\plugins\computer-use\scripts\computer-use-client.mjs:197:9)
    at NativePipeComputerUseTransport.create (...\plugins\openai-bundled\plugins\computer-use\scripts\computer-use-client.mjs:50:22)
    at setupComputerUseRuntime (...\plugins\openai-bundled\plugins\computer-use\scripts\computer-use-client.mjs:19:53)

Desktop logs

2026-06-05T20:28:58.090Z info [browser-use-native-pipe-server] browser-use native pipe listening pipePath=\\.\pipe\codex-browser-use-...
2026-06-05T20:28:58.440Z info [computer-use-native-pipe] computer-use notify config ensure finished platform=win32 reason=missing-helper-path status=skipped
2026-06-05T20:28:58.442Z warning [computer-use-native-pipe] computer-use native pipe startup failed errorMessage="Windows Computer Use helper paths are unavailable" errorName=Error platform=win32
2026-06-05T20:29:02.922Z info [BrowserUseThreadConfig] computer_use_native_pipe_thread_config_skipped platform=win32 reason=not-ready

Troubleshooting already tried

Uninstalled and reinstalled Codex Desktop.
Verified the new Codex package is installed and running.
Verified the Computer Use plugin and helper executable exist in the installed package.
Updated local config.toml so notify points at the helper in the currently installed Codex package.
Fully restarted Codex after updating config.toml.
Retested with a clean JavaScript runtime session.
Confirmed Browser Use works and creates its own native pipe.
Confirmed no Computer Use pipe is visible under \\.\pipe\.

This looks like the Desktop app cannot resolve Windows Computer Use helper paths, so it never injects SKY_CUA_NATIVE_PIPE_DIRECTORY or nodeRepl.nativePipe.createConnection into the session.

Adding a newer data point and a more specific root-cause link for this same Windows Computer Use helper paths are unavailable symptom.

I hit this on 2026-06-08 with:

Windows 11 Pro 25H2 / 10.0.26200 x64
Codex Desktop: OpenAI.Codex_26.602.4764.0_x64__2p2nqsd0c76g0
computer-use@openai-bundled installed, enabled 26.602.40724
The Computer Use helper binary and computer-use-client.mjs both existed in the stable plugin cache

In this case, the immediate precursor was not entitlement or a missing packaged helper. The Desktop log showed the Computer Use pipe had started successfully, then bundled marketplace resolution failed with EBUSY while trying to remove:

%USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled\plugins\chrome\extension-host\windows\x64

After that, the generated openai-bundled marketplace was left partial: it only contained plugins\chrome, and was missing .agents\plugins\marketplace.json plus plugins\computer-use. The log then switched to:

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"

Restoring the generated marketplace manifest/directories from the installed app bundle made openai-bundled visible again, and a live smoke test with setupComputerUseRuntime(...) + sky.list_apps() succeeded, returning 40 apps.

I added the detailed timeline to #26785 because it looks like one concrete cause of the helper-path symptom here: Chrome's native host can lock the generated bundled marketplace, leave it half-materialized, and then Computer Use helper-path resolution disappears even though the installed Computer Use package/cache is intact.

I’m seeing the same Windows Computer Use failure on Codex Desktop after a conservative reinstall and targeted cache reset.

Environment:

Windows 11 x64
Codex Desktop Microsoft Store package: OpenAI.Codex_26.602.9276.0_x64__2p2nqsd0c76g0
Codex Desktop version shown by package: 26.602.9276.0
Native Windows agent / PowerShell, not WSL

Observed behavior:

Settings > Computer Use shows the plugin as unavailable / disabled.
nodeRepl.requestMeta does not contain any computerUse or native pipe metadata.
Attempting to initialize Computer Use fails with:

Computer Use native pipe path is unavailable

Recent desktop logs repeatedly show:

[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
[BrowserUseThreadConfig] computer_use_native_pipe_thread_config_skipped platform=win32 reason=not-ready

Additional diagnostics:

Browser-use native pipe does start, e.g. codex-browser-use-... is listening.
The Computer Use helper exe exists in both the Store package and plugin cache:
- Store package: app/resources/plugins/openai-bundled/plugins/computer-use/node_modules/@oai/sky/bin/windows/codex-computer-use.exe
- Plugin cache: .codex/plugins/cache/openai-bundled/computer-use/26.527.31326/node_modules/@oai/sky/bin/windows/codex-computer-use.exe
owl-feature-bootstrap-cache.json regenerates as {"enabledOwlFeatureNames":[]}.

Things tried without resolving it:

Microsoft Store uninstall/reinstall via winget.
Confirmed package status is Ok.
Opened Settings > Computer Use after reinstall; plugin remains unavailable / button disabled.
Targeted reset of .codex/computer-use, .codex/plugins/cache/openai-bundled/computer-use, and owl-feature-bootstrap-cache.json.
Confirmed config.toml has no UTF-8 BOM.
Confirmed project is not running the agent in WSL.
Checked EFS/encryption state for helper exe; files are not encrypted.
Tried adding missing latest junctions for bundled plugin cache; no change.

This still reproduces after restart on 26.602.9276.0, with the same missing-helper-path / Windows Computer Use helper paths are unavailable log entries.

Additional reproduction on a newer Codex Desktop build.

Environment

Codex Desktop: 26.611.8273.0
Codex CLI: 0.140.0-alpha.19
OS: Windows 11 Professional, Windows NT 10.0.26200.0, x64 / AMD64
Agent environment: Windows native, PowerShell 5.1
Auth mode from codex doctor --all: ChatGPT auth, stored API key = false, stored ChatGPT tokens = true
computer-use@openai-bundled: enabled in config.toml
requirements.toml: not present; no local computer_use = false policy found

What was checked

Plugin/cache layer appears present:

computer-use/latest exists
computer-use-client.mjs exists
The previous missing computer_use_client_base.js import error is no longer the active failure in this repro
Marketplace and plugin files are present

Named pipes currently present:

\\.\pipe\codex-ipc
\\.\pipe\codex-browser-use-3e14b23b-fbde-4e1d-9d5c-af1d8a8cb43a
\\.\pipe\LOCAL\mojo.plugin_browser_pipe_Default_

No codex-computer-use-*, CUA, or sky-related pipe is created.

Node/tool environment inspection:

{
  "hasConfig": false,
  "hasNativePipe": false,
  "envKeys": [],
  "skyPipe": null,
  "codexHome": null
}

Computer Use bootstrap still fails with:

{
  "ok": false,
  "error": "Error: Computer Use native pipe path is unavailable"
}

Relevant desktop logs

Current build logs repeatedly show:

[computer-use-native-pipe] computer-use native pipe helper paths unavailable missingHelperPath=true missingTransportModulePath=true platform=win32

Browser native pipe starts successfully in the same session:

[browser-use-native-pipe-server] browser-use native pipe listening pipePath=\\.\pipe\codex-browser-use-...
[electron-message-handler] browser_use_availability_resolved available=true browserPane=true platform=Windows reason=available

Earlier logs from the same machine also showed:

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

Conclusion

This still reproduces on 26.611.8273.0: Computer Use plugin files exist, but Codex Desktop never starts or injects the Windows Computer Use native pipe. Browser-use pipe exists and works, but no Computer Use pipe is created, and the current turn receives no nodeRepl.nativePipe / SKY_CUA_NATIVE_PIPE_DIRECTORY.

Same issue on Windows. Backend runtime is fully present but the native pipe is never created by the host.

Environment:

Codex Desktop (Windows) App version: 26.616.10790.0
computer-use plugin: 26.616.81150 (pulled 2026-06-25)
cua_node runtime: present and complete
@oai/sky present at:
C:\Users<user>\AppData\Local\OpenAI\Codex\runtimes\cua_node\a89897d3d9baa117\bin\node_modules@oai\sky

Symptom:

After fully quitting and restarting Codex Desktop, no \.\pipe\codex-computer-use-* named pipe exists.
The plugin, cua_node runtime and @oai/sky are all in place; only the host-side native pipe fails to start.
node_repl session never receives nodeRepl.nativePipe / SKY_CUA_NATIVE_PIPE_DIRECTORY.

So this is a host-side native pipe / helper-path startup failure, not a missing/corrupt cache. Restart did not help.

Same issue on Windows. Backend runtime is fully present but the native pipe is never created by the host.

Environment:

Codex Desktop (Windows) App version: 26.616.10790.0
computer-use plugin: 26.616.81150 (pulled 2026-06-25)
cua_node runtime: present and complete
@oai/sky present at:
C:\Users<user>\AppData\Local\OpenAI\Codex\runtimes\cua_node\a89897d3d9baa117\bin\node_modules@oai\sky

Symptom:

After fully quitting and restarting Codex Desktop, no \.\pipe\codex-computer-use-* named pipe exists.
The plugin, cua_node runtime and @oai/sky are all in place; only the host-side native pipe fails to start.
node_repl session never receives nodeRepl.nativePipe / SKY_CUA_NATIVE_PIPE_DIRECTORY.

So this is a host-side native pipe / helper-path startup failure, not a missing/corrupt cache. Restart did not help.

same thing here. Is a special node version necessary?

Still reproducible on 26.721.4979.0; `cua_node` relocation fails on an application-protected secondary AppX volume

I can confirm that this issue still affects the current Windows desktop package after an app update.

Environment

Codex package: OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0
Windows 11 25H2, build 26200.8875, x64
The reported install path under C:\Program Files\WindowsApps\... is a junction whose target is D:\WindowsApps\OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0
D: is NTFS and healthy
cipher /c reports the packaged runtime file as application protected:

E CHANGELOG.md
  Compatibility Level:
    Application Protected

The file attributes reported by PowerShell are Archive, Encrypted.

Failure

After updating Codex, Computer Use failed with:

Windows Computer Use Sky runtime is unavailable

The desktop logs showed bundled_executable_relocation_failed while relocating the bundled cua_node directory. The failing source file was:

...\app\resources\cua_node\bin\CHANGELOG.md

The underlying operation was copyfile and surfaced as UNKNOWN. Relocation aborted, leaving the versioned directory under %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node incomplete/missing. This was followed by node-repl-missing and the Computer Use native pipe being unavailable.

Repeated app repair/reinstall and Windows restarts did not resolve it because the same relocation step failed again after update.

Confirmation of the relocation root cause

As a diagnostic workaround, I read the exact files from the signed MSIX package with normal read streams, copied them to a staging directory under %LOCALAPPDATA%, verified file counts, total sizes, and SHA-256 hashes for manifest.json, bin/node.exe, and bin/node_repl.exe, then atomically placed the result at the runtime hash directory expected by this build:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\f8d2abcb7481383b

No package files were modified. After this one-time relocation:

node_repl.exe started from the expected local runtime directory;
the codex-computer-use-* named pipe appeared;
setupComputerUseRuntime() succeeded;
sky.list_apps() succeeded and returned 40 apps.

This confirms that the bundled runtime itself is valid and that the failure is specifically in the WindowsApps-to-LocalAppData directory copy path for application-protected files on a secondary AppX volume.

Suggested fix

Please make bundled-directory relocation tolerate application-protected/EFS-backed AppX files on secondary package volumes. In particular, when the direct copyFile operation fails with the Windows encryption error surfaced as UNKNOWN, a buffered read/write stream fallback should work, followed by the existing staging validation and atomic rename. This should also prevent every app update from recreating the failure with a new runtime hash directory.

Disclosure: I maintain WinBridge Recovery.

available=true followed by Windows Computer Use helper paths are unavailable is a particularly useful symptom because it points past the entitlement gate and toward local runtime/materialization state. WinBridge Recovery checks that layer on Windows: the installed Codex package, extracted cua_node runtime, bundled plugin cache/version pointers, and related local registration paths are compared before any repair is attempted.

If the helper-path failure is caused by a stale/missing user-side runtime or a post-update path/version mismatch, the tool can back up and rebuild the affected local state from the currently installed official Codex files. It does not patch the Store package or weaken the sandbox.

I would still keep the scope narrow: if the helper is genuinely absent/incompatible in the shipped build, or the failure is inside the native helper after a correct path has been supplied, that needs an upstream fix. This is mainly a recovery option for the local materialization/path-drift variant of the error.

This content is diagnosed by chatGPT. I can provide another data point for this issue on a newer Codex Desktop build.

Environment

Codex Desktop: OpenAI.Codex 26.903.8094.0
Windows x64, build 26200
Microsoft Store / MSIX install
Get-AppxDefaultVolume reports:

D:\WindowsApps

Get-AppxPackage OpenAI.Codex reports the apparent install location as:

C:\Program Files\WindowsApps\OpenAI.Codex_26.903.8094.0_x64__2p2nqsd0c76g0

However, that specific package directory is a junction:

LinkType : Junction
Target   : D:\WindowsApps\OpenAI.Codex_26.903.8094.0_x64__2p2nqsd0c76g0

The package is also physically present under D:\WindowsApps.

Protected runtime file

For:

app\resources\cua_node\bin\node_repl.exe

cipher /c reports:

E node_repl.exe
Compatibility Level:
    Application Protected

Startup behavior

Codex/ChatGPT Desktop initially failed to show any GUI. Multiple ChatGPT.exe processes were alive and responsive, but there was no visible window.

Repair/Reset had already been attempted and did not resolve the problem.

After killing all ChatGPT processes and launching the MSIX app again, several ChatGPT.exe processes started at approximately 23:10:58, but the GUI was still absent initially.

I did not manually copy node_repl.exe, use xcopy /G, or otherwise modify the runtime.

The following finalized runtime directory was subsequently created:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\b58ca2eaa616c2da

with approximately 4051 files and:

LastWriteTime: 23:14:04

Shortly afterward, the application opened normally.

At the time I inspected the runtime directory after recovery, there were no remaining .staging-* directories; only the finalized content-addressed runtime directory was present.

Observation

This does not prove that my instance hit the same ERROR_ENCRYPTION_FAILED / 0x80071770 failure reported in some related issues, because I did not capture that error during the failing launch.

However, the environment appears closely related:

secondary AppX volume (D:\WindowsApps)
        +
C:\Program Files\WindowsApps package junction
        +
Application Protected cua_node runtime
        +
initial headless startup
        +
eventual runtime materialization and recovery

In this case the runtime relocation/materialization appears to have eventually completed without a manual workaround, rather than remaining permanently stuck.

This may be useful for distinguishing a slow/intermittent relocation case from the permanent node_repl.exe staging failures reported in related Windows issues such as #41540 and #42501.

Navigation Menu

Repository navigation

Windows Computer Use native pipe fails: helper paths unavailable on 26.527.31326 #25571

Summary

Environment

Observed log evidence

Local package evidence

Expected behavior

Actual behavior

Why this seems distinct from entitlement gating

Troubleshooting already done

Request

Environment

Verified files

Runtime failure

Desktop logs

Troubleshooting already tried

Environment

What was checked

Relevant desktop logs

Conclusion

Still reproducible on 26.721.4979.0; `cua_node` relocation fails on an application-protected secondary AppX volume

Environment

Failure

Confirmation of the relocation root cause

Suggested fix

Environment

Protected runtime file

Startup behavior

Observation

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Windows Computer Use native pipe fails: helper paths unavailable on 26.527.31326 #25571

Description

Summary

Environment

Observed log evidence

Local package evidence

Expected behavior

Actual behavior

Why this seems distinct from entitlement gating

Troubleshooting already done

Request

Activity

github-actions commented on Jun 1, 2026

weiwei929 commented on Jun 1, 2026

weiwei929 commented on Jun 1, 2026

joemg1011 commented on Jun 5, 2026

3366452371-a11y commented on Jun 5, 2026

LuisAlves10 commented on Jun 5, 2026

Environment

Verified files

Runtime failure

Desktop logs

Troubleshooting already tried

VVittgenstein commented on Jun 8, 2026

AHxiaohei commented on Jun 9, 2026

Pilgrimagecoding commented on Jun 17, 2026

Environment

What was checked

Relevant desktop logs

Conclusion

joncascorria742-dev commented on Jun 24, 2026

joncascorria742-dev commented on Jun 24, 2026

fwilly commented on Jul 11, 2026

3109406559-code commented on Jul 27, 2026

Still reproducible on 26.721.4979.0; cua_node relocation fails on an application-protected secondary AppX volume

Environment

Failure

Confirmation of the relocation root cause

Suggested fix

zemeng5208 commented on Aug 12, 2026

JuxyL commented on Sep 9, 2026

Environment

Protected runtime file

Startup behavior

Observation

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Still reproducible on 26.721.4979.0; `cua_node` relocation fails on an application-protected secondary AppX volume