[Windows] Codex 26.707 cannot stage Browser runtime from EFS-protected WindowsApps files

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

• #32589
• #32403

Powered by Codex Action

Follow-up: still reproducible on 26.727

This remains reproducible on a newer Microsoft Store build.

Environment

• Codex Desktop package: OpenAI.Codex_26.727.6591.0_x64__2p2nqsd0c76g0
• Codex CLI bundled with the app: 0.146.0-alpha.9.2
• Windows 11 x64, Microsoft Store install
• Computer Use plugin is enabled; bundled-plugin auto-install is not disabled
• Reproduction session: 019fbe07-3f0c-7f91-82c2-2a9158dfe5f2

New evidence

The app's current bundled cua_node runtime is 0.0.6 (Sky 0.6.2), but its expected user-runtime directory fb8898c05a62885e is never created. Only an older runtime (0.0.1, Sky 0.4.10) remains locally.

The desktop log recorded 36 relocation failures while trying to stage the new runtime. The first failing file is again:

app\resources\cua_node\bin\CHANGELOG.md

The failure is:

bundled_executable_relocation_failed
operation=copy_directory
errno=-4094
code=UNKNOWN
syscall=copyfile

A read-only cipher /c check reports the WindowsApps source file as:

E  CHANGELOG.md
Compatibility Level: Application Protected

while the destination runtime directory is unencrypted.

The staging failure is followed by:

missingHelperPath=true
missingTransportModulePath=true
browser_use_setup_failed reason=node-repl-missing

At runtime there is no node_repl.exe or codex-computer-use.exe process, no Computer Use/CUA named pipe, and the affected task receives no privileged node_repl tool. The Computer Use skill text is loaded, but the execution bridge is absent.

The Store update from 26.721 to 26.727 completed successfully, and repeated app restarts did not change the result. This appears to confirm that the EFS/Application Protected relocation bug persists in 26.727 and directly prevents the trusted Computer Use runtime from being provisioned.

Related original report: #25220.

I maintain WinBridge Recovery for Windows Codex Desktop local-state failures: https://github.com/zemeng5208/winbridge-recovery

This report is directly relevant to the project's current experimental Application Protected/EFS path. WinBridge v3.1.1 already uses byte-stream (FileStream) copying plus source/destination SHA-256 verification when materializing official resources into a user-owned mirror, instead of relying only on the native copy path that is failing here with UNKNOWN / -4094.

I want to be precise about the limitation: I do not consider Application Protected/EFS support fully solved yet. The current code can read/copy/verify these resources on affected machines, but I am still treating multi-version Store-package validation and stronger signature validation as research work. The tool does not decrypt, take ownership of, patch, or change ACLs on WindowsApps.

For a machine showing exactly this state — packaged cua_node exists, source is readable/Application Protected, user runtime is empty or stale, and helper/transport paths are then missing — WinBridge can at least diagnose the package/runtime version split and attempt a verified user-side reconstruction from the already installed official package. If the failure is instead in the trusted bridge after all local resources are healthy, it will not claim to fix that upstream runtime layer.

Reproduced again on a newer Microsoft Store build.

Environment

• Codex Windows package: 26.818.5345.0
• Bundled plugin/runtime release: 26.818.41705
• Windows x64, Microsoft Store package
• Affected features: Browser / Chrome / Computer Use

Observed
The desktop log reports:

bundled_executable_relocation_failed
plugin_marketplace_folder_write_failed
errorCode=UNKNOWN
errno=-4094
syscall=copyfile

Affected payloads include cua_node, codex.exe, rg.exe, and bundled plugin metadata. The downstream state was:

missingHelperPath=true
missingTransportModulePath=true
browser_use_setup_failed ... reason=node-repl-missing

cipher /c reports the relevant WindowsApps source files as Application Protected. A normal copyFile-style copy fails, while a byte-stream read/write copy of the same files succeeds.

For diagnosis only, I copied the protected payloads using a version-aware stream-copy fallback into content-hash-addressed per-user directories and verified all expected hashes. After that:

• the Computer Use native pipe reached startup ready;
• BrowserUseThreadConfig selected the repaired node / node_repl runtime;
• Node reported v24.19.0;
• the official node_repl MCP server initialized successfully.

This provides a current-version confirmation that the underlying issue is compatibility between the relocation implementation and Application Protected WindowsApps resources, not an absent bundled payload.

A product fix should use a copy mechanism compatible with Application Protected package files, validate the completed destination, and self-heal into the current content-hash directory after each Store update. No raw logs are attached because they contain local metadata; sanitized excerpts can be provided if needed.