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

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   browser

   computer-use

   on Jul 13, 2026
2. github-actions commented on Jul 13, 2026

   

   github-actionsbot

   on Jul 13, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Windows Store 26.707.3748.0: EFS copyfile UNKNOWN breaks bundled marketplace and Computer Use native pipe #32589
   • Windows MSIX: Computer Use and pet creation fail because bundled runtime relocation leaves bin/cua_node empty #32403

   Powered by Codex Action
3. Ywb822ovo commented on Aug 1, 2026

   

   Ywb822ovo

   on Aug 1, 2026 – with ChatGPT Codex Connector

   More actions

   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.
4. zemeng5208 commented on Aug 12, 2026

   

   zemeng5208

   on Aug 12, 2026 – with ChatGPT Codex Connector

   More actions

   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.
5. likeke0402 commented on Aug 23, 2026

   

   likeke0402

   on Aug 23, 2026 – with ChatGPT Codex Connector

   More actions

   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.
6. jedliuai commented on Aug 29, 2026

   

   jedliuai

   on Aug 29, 2026

   More actions

   Adding a current-build reproduction and a small temporary workaround tool for affected Windows users.

   Environment

   • Windows 11 x64, build 26200
   • Microsoft Store / MSIX package: OpenAI.Codex
   • Reproduced on:
     • 26.825.3734.0
     • 26.825.4187.0

   Observed behavior

   After an automatic Codex Desktop update, the app starts several ChatGPT.exe processes but the main window stays blank / untitled / not responding. The app repeatedly creates incomplete runtime staging folders under:

   %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\.staging-<runtime-hash>-*
   

   For example, after 26.825.4187.0, the new runtime hash was:

   e4d75eceaa042f20
   

   Multiple .staging-e4d75eceaa042f20-* folders were created, each incomplete, while the previous repaired runtime cache from the older build remained unused.

   Additional evidence

   The packaged runtime is complete:

   <WindowsApps>\OpenAI.Codex_26.825.4187.0_x64__2p2nqsd0c76g0\app\resources\cua_node
   318.9 MB, 4680 files
   

   But normal copy paths fail when copying from WindowsApps to the user runtime cache. For example, robocopy failed with Windows error 6000, and PowerShell / .NET copy also failed when trying to preserve the source file attributes.

   cipher /c showed packaged runtime files such as manifest.json carrying EFS encryption / Application Protected attributes, while the target cache directory was unencrypted.

   A byte-stream copy workaround succeeds: read each packaged runtime file as bytes and write it as a new local file under the expected runtime hash folder. The resulting local files no longer carry the encrypted attribute, and Codex Desktop starts normally afterward.

   Temporary workaround tool

   I published a small Windows-only workaround repo here:

   https://github.com/jedliuai/codex-runtime-repair

   Release zip for non-technical users:

   https://github.com/jedliuai/codex-runtime-repair/releases/tag/v1.0.0

   Scope of the workaround:

   • Only touches %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node
   • Backs up incomplete .staging-* folders instead of deleting them
   • Rebuilds the current runtime cache from the bundled app\resources\cua_node
   • Copies via byte streams so EFS attributes are not preserved
   • Does not reset login state, chat history, registry, or Windows settings

   This is only intended as a temporary user-side mitigation until Codex Desktop handles this WindowsApps EFS / Application Protected materialization path upstream.