Windows Store 26.707.3748.0: EFS copyfile UNKNOWN breaks bundled marketplace and Computer Use native pipe

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

• #32403

Powered by Codex Action

Update (2026-07-15):

The original Windows plugin/runtime problem remains after multiple Microsoft Store updates.

Observed versions:

• 26.707.3748.0
• 26.707.8479.0
• 26.707.9981.0

On 26.707.9981.0, Browser, Chrome, and Computer Use are still unavailable or unreliable. Updating the Store package did not resolve the user-visible plugin problem.

The installation remains:

• Microsoft Store managed
• Store signed
• Unmodified

I have not decrypted WindowsApps files, patched app.asar, repackaged the MSIX, or replaced the official package.

The previously captured technical evidence remains:

• bundled_executable_relocation_failed
• copyfile UNKNOWN
• errno -4094
• missingHelperPath=true
• missingTransportModulePath=true
• computer_use_native_pipe_thread_config_skipped reason=not-ready

Existing complete user-side plugin/runtime copies were not sufficient because Desktop attempted a new packaged-resource relocation during startup and did not reuse the existing verified copies after the relocation failed.

Potentially related runtime-relocation report:
https://github.com/openai/codex/issues/32403

A separate Windows Chromium/DWM white-surface symptom is documented here:
https://github.com/openai/codex/issues/32783

I am not claiming that the rendering artifact has the same root cause as this EFS/relocation failure.

Same root cause confirmed on Codex Desktop 26.715.3651.0 / Windows 11 Pro 10.0.26200 (Store install) — in my case it also breaks pet creation ("Cannot start creating pet"), because the hatch-pet recommended skill fails to install with the identical copyfile ... UNKNOWN error out of the WindowsApps package.

I posted full diagnostics in https://github.com/openai/codex/issues/25220#issuecomment-5009878911. Extra data points supporting the byte-stream fallback fix proposed here:

• cipher /c shows "Compatibility Level: Application Protected"; cipher /d fails with "The parameter is incorrect" even elevated after takeown + Full Control — this protection sits below the ACL layer, users cannot decrypt it.
• Store reinstall redeploys the package with the same encrypted attributes, so reinstalling is not a workaround.
• Byte-stream reads succeed on every affected file. I stream-copied the whole app directory (9,494 files) to a plain folder with 0 failures, and running the cloned app fixes skill install, marketplace copy, and pet creation immediately — so an fs.readFile + fs.writeFile fallback when copyfile fails would fully resolve this.

Update (2026-07-27): this still reproduces on Microsoft Store Codex Desktop 26.721.4979.0 with bundled Browser / Chrome / Computer Use 26.721.41059 on Windows 11 x64 (build 26200).

The current build still emits the same protected-copy/relocation failure class:

• bundled_plugins_marketplace_resolve_failed / copyfile UNKNOWN
• bundled_executable_relocation_failed with errno -4094
• downstream browser_use_codex_cli_missing_for_node_repl_sandbox

The affected materialization chain now includes the bundled marketplace, Browser, cua_node, and the content-addressed codex.exe / rg.exe files used by the Node REPL sandbox.

For a diagnostic A/B test, I left the Store package and WindowsApps files untouched. I materialized exact files from the current package into the expected user-writable, content-addressed locations using a copy path compatible with Application Protected sources, then verified the destination files against the package sources. After a full Codex restart, Desktop selected those repaired paths and all of these real probes passed:

• workspace sandbox write
• Node REPL execution
• in-app Browser navigation and DOM read on https://example.com/
• Computer Use application enumeration

This shows the current signed package features work once the exact packaged files are present in the per-user locations; the Store update itself did not eliminate the protected-copy failure.

A separate workspace-sandbox failure caused by user TEMP / TMP inheriting inaccessible C:\Windows\Temp was found and fixed independently. I am not treating that as the cause of the WindowsApps copy failure.

Could a maintainer confirm which report should be canonical among #25220, #32403, #32589, #32732, and #34764, and whether the Windows copy path can fall back to byte-stream read/write while preserving the last known-good marketplace/runtime when copyfile returns -4094?

Disclosure: I maintain WinBridge Recovery, an independent Windows recovery/diagnostic project for Codex Desktop.

I want to be careful about scope here: the EFS / Application Protected copyfile UNKNOWN failure itself is an upstream Windows packaging/materialization problem, and WinBridge Recovery does not decrypt, take ownership of, or modify the WindowsApps package.

Where the project may still help is the downstream state: detecting that a materialization attempt failed, preserving a last-known-good user-side marketplace/runtime instead of treating the partial staging tree as authoritative, and validating whether complete versioned plugin/runtime files already exist before rebuilding pointers/registration.

The byte-stream results reported in this thread are also useful implementation evidence. I’m evaluating a strictly local, opt-in fallback that would read from the user’s already-installed official package into user-writable staging and verify the copied files before activation, rather than changing the protected package itself. I would not make that a default repair until it is version-aware and integrity-checked.

For now, the project should be viewed as a diagnostic/recovery aid for the state left behind by this failure, not as a claim that it fixes the EFS protection mechanism.

Adding a current-build reproduction and a code-level clue that may explain why the decrypted-destination fallback is not reached.

Environment

• Windows x64, build 26200
• Microsoft Store / MSIX Codex Desktop 26.814.5167.0
• Bundled Chrome payload 26.814.41407
• The package is registered on a non-system AppxVolume.

Reproduction and impact

I followed the documented Plugins remove/re-add Chrome flow. Removal completed, but reinstallation reported "Plugin installation failed."

The desktop log records:

• manual_plugin_install_failed: missing bundled runtime codex, node, and node_repl
• plugin_marketplace_folder_write_failed
• bundled_plugins_marketplace_resolve_failed
• bundled_executable_relocation_failed
• errno=-4094, code=UNKNOWN, syscall=copyfile

The affected WindowsApps resources are reported as Application Protected. After the failed reinstall, the Chrome latest pointer still resolves to the older 26.803.81509 payload, both v2 native-host state files contain an empty entries array, and the native-host manifest and HKCU registration are absent.

Possible fallback-gate bug

Static inspection of the shipped 26.814 bundle shows that the Windows copy helper already contains a CopyFileExW fallback using COPY_FILE_ALLOW_DECRYPTED_DESTINATION (0x00000008). However, its predicate only accepts error.errno === 6000.

Node/libuv exposes the actual protected-file failure as errno=-4094 / code=UNKNOWN, so the predicate is false and the intended fallback is skipped. No windows_encrypted_copy_fallback_started or succeeded event appears in the failing log.

A robust fix may need to normalize or unwrap the underlying Win32 encryption error before applying the predicate, and preserve the last-known-good marketplace/native-host state until a replacement staging tree validates.

The Chrome-native-host impact also matches #28950 and #32802.

No WindowsApps files, ownership, ACLs, EFS policy, app code, registry entries, native-host manifests, junctions, or Codex configuration were manually modified.