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

What version of the Codex App are you using (From “About Codex” dialog)?

26.707.3748.0

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

The Microsoft Store Codex package resources are EFS-encrypted. Codex Desktop's native copyfile operation fails with UNKNOWN / errno -4094 while relocating bundled plugins and cua_node.

Confirmed impact:

plugin_marketplace_folder_write_failed
bundled_plugins_marketplace_resolve_failed
Browser is removed with reason=not_in_bundled_marketplace_plugin_names
Computer Use reports missingHelperPath=true
Computer Use reports missingTransportModulePath=true
computer_use_native_pipe_thread_config_skipped reason=not-ready
The codex-computer-use-* native pipe is not created

The existing user-side seven-plugin marketplace and the existing 3,558-file cua_node runtime are already complete, but Desktop does not reuse them after relocation fails.

A full sanitized technical report is attached.

Codex-Windows-EFS-Copyfile-Bug-Report.pdf

What steps can reproduce the bug?

Install or launch the Microsoft Store package OpenAI.Codex_26.707.3748.0_x64__2p2nqsd0c76g0.
Start Codex Desktop normally.
Desktop creates a new openai-bundled.staging-<GUID> directory and attempts to copy bundled resources from WindowsApps.
Native copyfile fails on an EFS-encrypted packaged resource with UNKNOWN / errno -4094.
Marketplace reconciliation runs against the failed result and may remove Browser.
Computer Use initialization reports missingHelperPath=true and missingTransportModulePath=true.
No codex-computer-use-* native pipe is created.

The same EFS-encrypted source file can be read and written successfully using byte-stream operations, while native .NET File.Copy fails with "The specified file could not be copied."

Native copying also fails when using the real package path directly, bypassing the C:\Program Files\WindowsApps junction. Therefore, the failure is not caused by the drive location or junction.

What is the expected behavior?

Codex Desktop should initialize its bundled plugins and Computer Use runtime successfully from a Microsoft Store package whose resources are EFS-protected.

On Windows, Desktop should:

Fall back to byte-stream copying when native copyfile fails but the source file is readable.
Validate and reuse an existing complete versioned runtime when relocation fails.
Preserve the last known-good bundled marketplace when a new staging operation fails.
Avoid uninstalling bundled plugins based on an incomplete or failed staging result.
Create the codex-computer-use-* native pipe and inject valid helper and transport paths.
Keep Browser, Chrome, and Computer Use available after normal Desktop restarts.

Additional information

The existing user-side fallback data is already complete:

The bundled marketplace contains all seven current plugins: sites, browser, chrome, computer-use, latex, deep-research, and visualize.
File-by-file comparison found no missing official plugin files.
The existing user-side cua_node runtime contains exactly the same 3,558 files as the current Store package.
manifest.json, node.exe, node_repl.exe, and @oai/sky/package.json have matching SHA-256 values.
Chrome and Computer Use latest paths are native Windows NTFS junctions pointing to stable versioned cache directories.
The Chrome native messaging manifest points to a stable versioned host executable.

Despite this, Desktop performs a new relocation and marketplace staging operation during every launch and does not reuse the verified complete existing copies after native copying fails.

Approximately 20 abandoned openai-bundled.staging-<GUID> directories remain from repeated failed synchronization attempts. They contain incomplete directory structures and no complete marketplace.

The main ChatGPT/Codex application, Store signature, sign-in, conversation history, configuration, and custom skills remain healthy. The confirmed user-visible impact is Browser removal and Computer Use native-pipe failure.

A full sanitized technical report is attached. The same report has also been escalated to an OpenAI Support specialist.

I would like to preserve the official Microsoft Store signature and normal Store updates. I do not want to decrypt or modify WindowsApps, change its ownership or ACLs, patch app.asar, or replace the Store package with a developer-signed build.

Codex-Windows-EFS-Copyfile-Bug-Report.pdf

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

Windows MSIX: Computer Use and pet creation fail because bundled runtime relocation leaves bin/cua_node empty #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:
#32403

A separate Windows Chromium/DWM white-surface symptom is documented here:
#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 #25220 (comment). 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.

Additional reproduction on Microsoft Store package OpenAI.Codex 26.903.8094.0 (Windows x64), tested 2026-09-10. This adds a concrete error-normalization mismatch in the existing encrypted-copy fallback.

Observed impact

The desktop app and its CLI updated, but installed browser/chrome/computer-use plugins remained at 26.901.51231 while the new package shipped 26.903.61454. App logs repeatedly reported:

plugin_marketplace_folder_write_failed, errorCode=UNKNOWN, folderWritePhase=copy_plugins
bundled_plugins_marketplace_resolve_failed

The failing source was <StorePackage>/app/resources/plugins/openai-bundled/plugins/sites/.app.json; destination was <CODEX_HOME>/.tmp/bundled-marketplaces/openai-bundled.staging-<id>/plugins/sites/.app.json.

Independent reproduction

cipher /c identifies the 105-byte source as encrypted, compatibility level Application Protected.
Using the app-associated Node v24.20.0, fs.copyFile(source, destination) fails with {code:"UNKNOWN", errno:-4094, syscall:"copyfile"}.
Tested three fresh writable temporary destinations: a D: project directory, CODEX_HOME's .tmp on D:, and the user's Temp on C:. All three fail identically.
readFile(source) followed by writeFile(destination, bytes) succeeds in all three locations; SHA-256 matches the source content.
Independent .NET File.Copy fails with HRESULT -2147018896 (0x80071770), low-word Win32 error 6000 ("The specified file could not be encrypted").
CODEX_HOME and its .tmp are ordinary directories, not junctions. These results do not support moving CODEX_HOME back to C: or widening directory permissions as a solution.

Existing fallback appears to miss the actual Node error

Read-only inspection of the installed app's windows-file-copy-Dm31CRG0.js shows that the Windows fallback predicate accepts only error instanceof Error && error.errno === 6000. The module already implements a stream-based retry with cancellation/timeout handling.

However, the corresponding error surfaced by Node in the reproduction is -4094 / UNKNOWN, not 6000. Thus the predicate would reject the observed error before reaching the existing stream-copy fallback. This strongly explains the repeated marketplace-copy failure. The independent Node test was not instrumented inside Electron itself; the desktop logs independently show the matching UNKNOWN/copyfile failure.

Suggested investigation

Please normalize/identify this Windows encrypted-resource failure at the Node boundary and route it into the existing fallback, with appropriate source/context checks rather than treating every UNKNOWN error as an encryption failure. Preserve fallback errors, cancellation, staging validation, and the last known-good marketplace.

Scope / current workaround

The official Store package and app.asar were not modified for this investigation. This is not a pristine user configuration: CODEX_HOME is customized and user-side plugin/communication configuration had previously been repaired. Manual synchronization of the current marketplace and plugin registrations restored the current plugin versions, but does not fix future automatic updates. The current CLI binary matched the new package by SHA-256; no persistent user-level CODEX_CLI_PATH pin remained.

No credentials, personal paths, full logs, or conversation transcripts are attached.

Reproduced again on a much newer Windows Store build: OpenAI.Codex_26.908.4834.0 (2026-09-14).

This is still the same EFS / Application Protected copyfile UNKNOWN failure, and it now breaks the bundled Browser runtime/cache path as well.

Current reproduction details

Codex Desktop package: OpenAI.Codex_26.908.4834.0
Browser runtime expected by this build: 26.908.40834
Before repair, the user cache only contained older Browser runtime 26.903.71938
The entire expected cache directory for 26.908.40834 was missing, including:
- scripts/browser-client.mjs
- scripts/browser-service.mjs

I manually recovered the complete 26.908.40834 Browser plugin from the AppX package using byte-stream copying. 382 files matched the AppX source hashes exactly. Normal copy operations failed with the Windows error equivalent to “The specified file could not be encrypted”; the packaged source files have the Encrypted attribute. Byte-stream read/write succeeded.

After recovery, the expected Browser directory and both MJS modules existed correctly. However, after restarting Codex Desktop, the entire 26.908.40834 cache directory disappeared again.

Startup log evidence

On restart, the bundled-plugin reconciliation starts and the Browser cache parent is recreated immediately afterward. The marketplace staging then fails before Browser cache generation completes.

The failing source file in this run is:

plugins/sites/.app.json

Relevant log fields:

folderWritePhase=copy_plugins
errorCode=UNKNOWN
UNKNOWN: unknown error, copyfile ...\\plugins\\sites\\.app.json -> ...\\openai-bundled.staging-...\\plugins\\sites\\.app.json

The next log entry reports bundled marketplace resolution failure.

plugins/sites/.app.json also has the Windows Encrypted attribute. This matches the earlier direct-copy behavior: normal copy fails because of EFS/Application Protected semantics, while byte-stream copying succeeds.

User-visible impact

Once the new Browser cache is missing, the in-app Browser can still appear in the UI and the tab registry may still respond, but deeper automation becomes unreliable or unavailable. In this reproduction, page-level JavaScript execution (document.readyState) eventually failed even on example.com, and the Browser layer then reported that the required connection module was missing.

Why this is useful

This confirms the bug is still present in 26.908.4834.0, well after the original 26.707 report and the later 26.820 reproductions. It also confirms that manually restoring a complete, hash-matching Browser cache is not durable: startup reconciliation removes/rebuilds it, then staging fails again on an EFS/Application Protected packaged file.

The product-side fix still appears to require one or more of:

a Windows copy path equivalent to allowing decrypted destinations (or a byte-stream fallback),
preserving/reusing the last known-good bundled marketplace/runtime if staging fails,
avoiding deletion of a valid versioned Browser cache before the replacement staging operation has completed successfully,
surfacing the underlying Windows encryption error instead of only UNKNOWN.

No WindowsApps ownership/ACLs, package contents, or encryption settings were modified during this reproduction.

Reproduced on Windows Store package OpenAI.Codex_26.908.9136.0_x64__2p2nqsd0c76g0, with bundled Browser plugin 26.908.70816.

Observations

The in-app browser UI and existing local application tabs worked, but the current task did not receive the Browser skill.
The configured browser service path pointed into %USERPROFILE%/.codex/plugins/cache/openai-bundled/browser/26.908.70816/scripts/browser-service.mjs; that versioned directory was missing.
The corresponding complete Browser bundle was present in the installed Store package.
The packaged browser/.codex-plugin/plugin.json has Archive, Encrypted attributes.
A normal PowerShell Copy-Item -Recurse attempt failed repeatedly with The specified file could not be encrypted.

Current-session recovery verified

Reading each packaged file and writing its bytes into the expected per-user Browser cache succeeded. All 382 files were compared with the Store package sources using SHA-256: zero mismatches.

After restoring the cache, the supported browser runtime initialized successfully, selected Codex In-app Browser, listed the existing tabs, and read a real local application's accessibility tree. This verifies page-level access in the actual in-app browser, not a separate Playwright browser.

The Store package, WindowsApps ownership/ACLs, encryption settings, and app.asar were not modified. No browser permission changes were needed. This was a repair of an existing installation, not a clean-install test.

I have not tested persistence across another restart or update. In light of the previous report that startup reconciliation removes the repaired directory, this is a current-session workaround rather than a product fix. The evidence supports the requested protected-file-compatible copy fallback and preservation of valid cached bundles when staging fails.

I can reproduce the same underlying Windows EFS/Application Protected copy failure through the Claude/Cowork external-agent import path in Codex Desktop for Windows.

Environment:

Windows 11 x64
Microsoft Store Codex Desktop 26.1002.7124.0
Claude Desktop installed from the Microsoft Store
Before the workaround, the desktop setting external-agent-import-sync-enabled was true.

Observed:

On each Codex startup, the app logs "Failed to sync external agent imports".
The failure is a native copy operation: "UNKNOWN: unknown error, copyfile".
The source is Claude's MSIX LocalCache skills bundle, ending in ".claude-plugin/plugin.json".
cipher /c reports the source as encrypted with "Compatibility Level: Application Protected"; the Codex user cache destination is unencrypted.
Windows Copy-Item/.NET File.Copy reproduces "The specified file could not be encrypted".
Reading the source bytes and writing them through a normal byte stream succeeds.

The failing operation is only copying the plugin/skill files; no chat transcript or secret was included in the failing path. The visible impact was the sync toast on every restart.

Workaround used locally:

[desktop]
external-agent-import-sync-enabled = false

This looks like the same protected-file materialization problem reported here, but in the external-agent import path. A robust fix would be to fall back to streamed copying when the source is readable, preserve a last-known-good cache when staging fails, and report the Windows error instead of generic "UNKNOWN".

Navigation Menu

Repository navigation

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

What version of the Codex App are you using (From “About Codex” dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Environment

Reproduction and impact

Possible fallback-gate bug

Observed impact

Independent reproduction

Existing fallback appears to miss the actual Node error

Suggested investigation

Scope / current workaround

Current reproduction details

Startup log evidence

User-visible impact

Why this is useful

Observations

Current-session recovery verified

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

What version of the Codex App are you using (From “About Codex” dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Jul 12, 2026

Jack-zhuo123 commented on Jul 14, 2026

g1331 commented on Jul 18, 2026

Shallow-dusty commented on Jul 27, 2026

zemeng5208 commented on Aug 12, 2026

fichil commented on Aug 20, 2026

Environment

Reproduction and impact

Possible fallback-gate bug

lyjunnb commented on Sep 10, 2026

Observed impact

Independent reproduction

Existing fallback appears to miss the actual Node error

Suggested investigation

Scope / current workaround

ywddd-git commented on Sep 14, 2026

Current reproduction details

Startup log evidence

User-visible impact

Why this is useful

piotrnowakowski commented on Sep 15, 2026

Observations

Current-session recovery verified

GoZippy commented on Oct 9, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions