[Windows] Bundled plugins (Computer Use, Browser, Chrome, LaTeX) unavailable — copyfile fails on EFS-encrypted WindowsApps files

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

• #25194

Powered by Codex Action

Additional data point from the same Windows Store build family. This appears to affect more than just Computer Use; other bundled plugins are also missing/unavailable in the UI after the update.

Environment:

• OS: Windows 11 Pro
• Codex package: OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0
• Installed via Microsoft Store / Windows Update
• Windows Update installed the Codex update on May 29, 2026

Symptoms:

• Settings > Computer use shows: Computer Use plugins unavailable
• Other bundled plugins also appear missing/unavailable after the update
• computer-use is still enabled in config.toml
• Computer Use plugin files exist on disk
• Installed app bundle contains computer-use plugin version 26.527.31326
• Local plugin cache still has computer-use version 26.527.30818
• chrome@openai-bundled logs missing or invalid plugin.json

Computer Use health check fails before reaching Windows automation:

Computer Use native pipe path is unavailable

Node REPL runtime state:

hasNativePipeObject: false
hasCreateElicitation: true
SKY_CUA_NATIVE_PIPE_DIRECTORY: missing
nodeRepl.nativePipe: missing

Process / pipe evidence:

No running codex-computer-use process
No Computer Use named pipe under \\.\pipe\

There had been a codex-computer-use client alive earlier on May 29, but after the update/restart there is no helper process and no native pipe available to the plugin session.

This looks like Codex Desktop is failing to reconcile/start/expose the bundled plugin native IPC services after the update, rather than the user disabling Computer Use or the plugin being completely absent.

I submitted a bug report (019e77ef-a2c0-73c1-aeee-01cfffa81c1a contains details) showing that after the most recent public update Computer Use shows the same pipe missing error and Chrome plugin has regressed and no longer functions. This is the most similar open issue I could find to my errors. I have replicated the issue on three separate devices and 2 different ChatGPT accounts. Running Diagnose issues in Codex Workspace returns Codex dependencies look healthy.

Follow-up: full clean reinstall resolved this on my machine.

I do not know if this confirms the root cause, but it may help narrow the failure mode.

What fixed it for me:

• Fully uninstalled the Codex Windows app
• Fully uninstalled the Codex CLI
• Closed/killed remaining Codex-related processes
• Deleted remaining .codex folders under my user profile
• Reinstalled the Codex Windows app
• Reinstalled the Codex CLI
• Reopened Codex and confirmed bundled plugins were available again

Important detail from cleanup: deleting .codex was initially blocked by a bundled Chrome extension-host.exe path inside .codex plugin/cache/temp folders, which makes me think stale or locked per-user bundled plugin state may survive the app update and prevent the updated app from reconciling/starting bundled plugins cleanly.

After the clean reinstall, Computer Use works again for me.

I would not recommend this as a normal user workaround without warning, because deleting .codex is effectively a destructive reset. But as a diagnostic datapoint: clearing the app/CLI plus per-user .codex state fixed the bundled plugin unavailable state on Windows 11 Pro.

Adding another Windows reproduction with extra diagnostics. I originally suspected this might be a local cache/home migration issue, but after a clean reset and reinstall it still reproduces.

Environment

• Codex app package: OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0
• Install method: Microsoft Store
• OS: Windows 11, x64
• Network/region checks: reproduced with system-level egress in both Singapore (SG) and United States (US), so this does not look like only the EEA/UK/CH region gate.
• Accounts: reproduced with two different ChatGPT/Codex accounts on the same Windows machine.

User-visible symptom

Settings → Computer Use shows:

Computer Use plugins unavailable
Always-allowed apps
None yet

No Install button is shown.

What was tried

1. Clean home/config/cache migration check

The Codex/Claude home path changes were ruled out:

• CODEX_HOME and CODEX_SQLITE_HOME cleared.
• Codex active home reset to %USERPROFILE%\.codex.
• Later performed a full clean reset: moved/removed .codex, %LOCALAPPDATA%\OpenAI\Codex, %LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0, cleared workaround env vars, uninstalled Codex, rebooted, reinstalled from Store.
• After clean reinstall and login, Computer Use still showed unavailable.

2. WindowsApps/Application Protected copy behavior

Source files inside the Store package show EFS/Application Protected behavior. Copy-Item fails when copying from C:\Program Files\WindowsApps\OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0\app\resources\...:

The specified file could not be encrypted.

Directory EFS pollution was ruled out: %TEMP%, %LOCALAPPDATA%, %USERPROFILE%, C:\Users\Public, C:\Windows\Temp, and D:\data\save_tmp all showed U / “New files added to this directory will not be encrypted.”

Observed copy-method difference:

• Copy-Item: fails with The specified file could not be encrypted
• cmd copy /b: fails with the same error
• robocopy: succeeds
• .NET File.Copy: succeeded in one source copy test, but later the safer workaround was to use robocopy

3. Manual prewarm workaround did not make the app recognize Computer Use

Manually copied/prewarmed these binaries to %LOCALAPPDATA%\OpenAI\Codex\bin:

codex.exe
node.exe
node_repl.exe
rg.exe
codex-command-runner.exe
codex-windows-sandbox-setup.exe

Verified local bin was unencrypted:

U bin

Also copied/decrypted bundled marketplace/plugin cache:

%USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled
%USERPROFILE%\.codex\plugins\cache\openai-bundled

Verified important files were present and U:

%USERPROFILE%\.codex\plugins\cache\openai-bundled\.agents\plugins\marketplace.json
%USERPROFILE%\.codex\plugins\cache\openai-bundled\plugins\computer-use\.codex-plugin\plugin.json

Also tried adding the bundled marketplace and enabling plugins in %USERPROFILE%\.codex\config.toml:

[marketplaces.openai-bundled]
source = '\\?\C:\Users\Administrator\.codex\plugins\cache\openai-bundled'

[plugins."browser@openai-bundled"]
enabled = true

[plugins."chrome@openai-bundled"]
enabled = true

[plugins."computer-use@openai-bundled"]
enabled = true

[plugins."latex@openai-bundled"]
enabled = true

Also set helper env vars based on a community workaround:

CODEX_CLI_PATH=%LOCALAPPDATA%\OpenAI\Codex\bin\codex.exe
NODE_REPL_NODE_PATH=%LOCALAPPDATA%\OpenAI\Codex\bin\node.exe

Even after restarting Codex/Windows, the UI still showed Computer Use plugins unavailable.

4. SQLite/log observation

Logs showed plugin sync completing with an empty installed plugin set:

completed remote installed plugin bundle sync installed_plugin_ids=[] removed_cache_plugin_ids=[] failed_remote_plugin_ids=[]

This seems important: after manually making files/config available, the app still appears to not consider computer-use@openai-bundled installed/available.

Current conclusion

This no longer looks like only stale local state or a user home/cache migration problem. After clean reset + Store reinstall + testing with two accounts + non-restricted network egress, the Windows app still shows Computer Use unavailable.

There may be two related issues here:

1. The Store/MSIX WindowsApps package resources are Application Protected, and some copy paths fail with The specified file could not be encrypted.
2. Even after manually prewarming the local cache and enabling computer-use@openai-bundled, Codex still reports no installed plugins / does not expose Computer Use.

It would be helpful if Codex could either:

• avoid a copy API that preserves/propagates the protected/encrypted attribute from WindowsApps, or
• read bundled plugin metadata directly from the installed app package, or
• provide a clearer diagnostic in Settings when Computer Use is disabled by feature flag/rollout/account policy rather than local plugin files.

I hit what appears to be the same Windows bundled-plugin issue and found a workaround that has survived repeated restarts of the Codex app.

Environment:

• Codex Desktop: 26.527.3686.0
• Bundled plugin version: 26.527.31326
• Windows, Microsoft Store / WindowsApps install

Symptoms observed:

• Settings showed Browser / Computer Use as unavailable.
• Logs repeatedly contained:
• Windows Computer Use helper paths are unavailable
• reason=missing-helper-path
• bundled_plugins_marketplace_resolve_failed ... EBUSY ... rmdir ... chrome\\extension-host\\windows\\x64
• bundled_plugin_install_skipped_missing pluginName=computer-use
• browser_use_availability_resolved available=true was often present, so Browser itself was actually able to start; the UI/plugin state seemed to be confused by the bundled marketplace/cache state.

The key local finding was that the generated runtime marketplace under:

%USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled

could become incomplete. In the broken state it only contained part of the Chrome extension-host tree, while the installed app resources still had the complete marketplace including browser, chrome, computer-use, and latex:

<OpenAI.Codex install location>\app\resources\plugins\openai-bundled

In that state, computer-use was absent from the user plugin cache, including the helper:

%USERPROFILE%\.codex\plugins\cache\openai-bundled\computer-use\26.527.31326\node_modules\@oai\sky\bin\windows\codex-computer-use.exe

Workaround that fixed it locally:

1. Stop all Codex-related processes.
2. Re-register the openai-bundled marketplace to the installed app resources directory, not the generated .codex\.tmp\bundled-marketplaces directory.
3. Ensure the bundled plugins are present in %USERPROFILE%\.codex\plugins\cache\openai-bundled, especially computer-use.

The rough PowerShell shape is:

$pkg = Get-AppxPackage OpenAI.Codex
$market = Join-Path $pkg.InstallLocation "app\resources\plugins\openai-bundled"
$codex = (Get-ChildItem "$env:LOCALAPPDATA\OpenAI\Codex\bin\*\codex.exe" | Sort-Object LastWriteTime -Descending | Select-Object -First 1).FullName

# If openai-bundled is already registered to the broken temp path, remove/re-add or otherwise update it.
& $codex plugin marketplace add $market

# Then make sure browser/chrome/computer-use are installed/enabled from openai-bundled.
# In my local workaround I also mirrored the installed bundled plugin folders into:
# %USERPROFILE%\.codex\plugins\cache\openai-bundled\<plugin>\26.527.31326

After doing that, normal launching from the Codex desktop icon started working again. Logs changed from missing-helper-path to computer-use notify config ensure finished ... status=already-present / status=installed.

This looks like a startup/reconcile race or source mismatch: Codex writes the runtime bundled marketplace under .codex\.tmp, but the Chrome extension-host path can be busy, leaving that generated marketplace incomplete. Subsequent plugin installation then treats computer-use as missing even though it is present in the installed app resources.

I can confirm a very similar issue on another Windows installation.

Environment

• Codex Windows app: latest installed/reinstalled from the Windows app flow; local bundled plugin version observed under .codex/plugins/cache/openai-bundled: 26.527.31326
• OS: Windows Home China, x64
• Chrome: installed, version 148.0.7778.217

User-visible symptoms

• The Chrome plugin cannot be found in the Codex Plugins UI even after uninstalling and reinstalling Codex.
• Computer Use is shown as unavailable.
• The user can use task/computer features from ChatGPT mobile, but the local Codex Windows desktop plugins remain unavailable.

Local diagnostics

Bundled plugin packages exist locally:

%USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome\26.527.31326
%USERPROFILE%\.codex\plugins\cache\openai-bundled\computer-use\26.527.31326

Chrome extension is installed and enabled:

{
  "extensionId": "hehggadaopoacecdllhhajmbjkdcmajg",
  "installed": true,
  "enabled": true,
  "selectedProfileDirectory": "Default",
  "versions": ["1.1.5_0"]
}

But the Chrome native host is still missing after reinstall:

HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension
%LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json

Diagnostic output reports:

Windows native host registry key does not exist: HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension; Native host manifest does not exist: %LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json

Attempting to bootstrap the Chrome backend from the desktop thread fails before tab access, with the Node/browser runtime exiting unexpectedly and reporting:

windows sandbox failed: spawn setup refresh

This looks like the bundled plugin package/cache exists, but the desktop app is not activating the plugin UI entry and is not installing/restoring the native host for Chrome. Reinstalling Codex did not restore the missing native host or make Chrome/Computer Use usable.

There are numerous issues on Windows Desktop Codex related to openai-bundled plugins, and the community still has no fundamental fix — this deserves official attention.

On my machine, the Windows Desktop Codex also has openai-bundled plugins completely unavailable. What's more frustrating is that I asked Codex to fix it itself, and it repeatedly exhausted the 5-hour usage limit multiple times without making any progress on this issue. This has severely degraded the Codex user experience.

I believe that such critical core functionality being unavailable should be treated with considerable urgency, and I hope to see an official fix soon.
@codex

Same situation here. I just can't control my browser using the extension nor my computer via computer use.

Adding a confirmed workaround that restored Browser+ Computer Use for me without another full reinstall.

Environment

• Windows 11 Pro x64
• Codex Store package: OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0
• Codex CLI: 0.135.0
• Bundled plugin version: 26.527.31326

Broken state

My broken state matched this issue:

• Browser showed unavailable
• Computer Use showed unavailable
• openai-bundled was configured to use:

%USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled

• That generated marketplace was incomplete. It only had part of the Chrome extension-host tree and was missing the full bundled marketplace/plugin metadata.
• codex plugin marketplace list did not show openai-bundled
• Computer Use failed with:

Computer Use native pipe path is unavailable

Workaround that fixed it

I copied the complete bundled marketplace out of the Store app package into a normal user-owned .codex path, then re-registered openai-bundled there.

$pkg = Get-AppxPackage OpenAI.Codex
$source = Join-Path $pkg.InstallLocation "app\resources\plugins\openai-bundled"
$dest = Join-Path $env:USERPROFILE ".codex\bundled-marketplaces\openai-bundled"

New-Item -ItemType Directory -Force -Path (Split-Path -Parent $dest) | Out-Null
robocopy $source $dest /MIR /XJ /R:2 /W:1

codex plugin marketplace remove openai-bundled
codex plugin marketplace add $dest

Then I restarted Codex Desktop.

Result after restart

• browser@openai-bundled showed installed/enabled
• computer-use@openai-bundled showed installed/enabled
• In-app Browser worked
• setupComputerUseRuntime() worked
• sky.list_apps() returned apps/windows
• Computer Use successfully targeted Task Manager and captured window state

One extra finding: pointing openai-bundled directly at the WindowsApps package path fixed plugin discovery, but Browser runtime loading hit Access is denied on a native module under the protected package path. So the user-owned copy was the part that made the workaround actually work.

This looks like the generated .codex\.tmp\bundled-marketplaces\openai-bundled marketplace can become incomplete, and Codex then keeps using that bad generated marketplace. Validating/regenerating that marketplace, or staging it into a user-owned path more reliably, may fix the issue.

Thanks for the detailed Windows repro and follow-up diagnostics. I maintain a small community Codex Skill focused specifically on Windows Codex Desktop failures around the bundled Chrome and Computer Use plugins:

https://github.com/navi118/codex-desktop-doctor-skill

It is not a general Codex repair script, and it does not make automatic destructive changes. The goal is to help an agent collect the relevant local evidence first, especially around the Codex Chrome Extension/native host, Computer Use helper/native pipe, bundled marketplace/cache state, and Windows file-lock / access-denied patterns such as plugin_cache_windows_file_lock, EBUSY, os error 5, missing-helper-path, or Windows Computer Use helper paths are unavailable.

This may or may not be the same root cause for every report in this thread, but the diagnostic checklist may help separate:

• bundled marketplace/cache reconciliation failures,
• Chrome extension/native host registration problems,
• Computer Use helper/native pipe availability failures,
• and cases where plugin files exist but the active Codex runtime does not expose the backend.

Sharing it here as a cautious evidence-gathering aid for this Windows Chrome/Computer Use class of bugs.

I hit this on Windows too. What fixed it for me was fully closing Chrome, stopping the Codex Chrome extension extension-host.exe process, then renaming these cache folders so Codex could rebuild them:

• %USERPROFILE%\.codex\.tmp\bundled-marketplaces
• %USERPROFILE%\.codex\plugins\cache\openai-bundled
• %USERPROFILE%\.codex\plugins\openai-bundled

After reopening Codex and waiting 1-2 minutes, Browser / Chrome / Computer Use came back. In my case, just closing Codex was not enough because the Chrome extension host was still holding the bundled plugin cache.

Same issue here on Windows 11 Home China (Build 26200), Codex Desktop 26.602.3474.0 via Microsoft Store.

Computer Use showed plugins unavailable in Settings. Logs kept hitting missing-helper-path and bundled_plugins_marketplace_resolve_failed.

What I found:

The app tries to copy bundled plugins from the EFS-protected WindowsApps directory to ~\.codex\.tmp\bundled-marketplaces\ on startup, but Node.js fs.copyFile can't handle encrypted files. The whole bundled marketplace ends up incomplete — only Chrome's extension-host tree made it through, while computer-use, browser, and latex were silently dropped.

What worked for me:

Pointed marketplaces.openai-bundled source in config.toml directly at the app's own plugin directory instead of the .codex\.tmp staging path:
source = '\\?\C:\Program Files\WindowsApps\OpenAI.Codex_26.602.3474.0_x64__2p2nqsd0c76g0\app\resources\plugins\openai-bundled'
Used robocopy (not Copy-Item — it also fails on EFS) to copy the computer-use plugin into ~\.codex\plugins\cache\openai-bundled\computer-use\<version>, then created a latest junction pointing to it.
Updated the notify path in config.toml to match the correct version.
Restarted Codex. Logs changed from missing-helper-path to status=installed. Computer Use is working now.
Caveat: This will break again after a Store update since the version folder under WindowsApps changes. You'd need to repeat the copy + config update.

This is basically the same as what @endfish described earlier — the bundled marketplace reconciliation fails because of EFS encryption on Windows Store packages. Hope OpenAI can fix this upstream, maybe by using robocopy or File.Copy instead of fs.copyFile, or by reading plugin metadata directly from the app package

Another data point that appears to match this issue very closely.

Primary machine:

• Codex package: OpenAI.Codex_26.602.3474.0_x64__2p2nqsd0c76g0
• Previously also reproduced on 26.601.2237.0
• Codex local version file: 0.136.0
• OS: Windows 10 Pro x64
• OS build: 26200

User-visible symptom:

• In Settings > Computer Use, the app shows:
• Computer Use plugins unavailable
• Always-allowed apps: None yet

The local logs on this machine show the same general failure chain described here:

• reason=missing-helper-path
• Windows Computer Use helper paths are unavailable
• bundled_plugins_marketplace_resolve_failed
• bundled_executable_relocation_failed
• browser_use_setup_failed ... reason=node-repl-missing

Relevant current-log excerpt:

[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"
[BundledPluginsMarketplace] bundled_plugins_marketplace_resolve_failed ... copyfile ... plugins\\computer-use\\.codex-plugin\\plugin.json
bundled_executable_relocation_failed ... copyfile ... codex.exe
bundled_executable_relocation_failed ... copyfile ... node.exe
bundled_executable_relocation_failed ... copyfile ... node_repl.exe
[BrowserUseThreadConfig] browser_use_setup_failed backend=node_repl phase=runtime-paths platform=win32 reason=node-repl-missing

I also reproduced the copy behavior locally outside the app:

• Using Node fs.copyFileSync from the Microsoft Store package under C:\Program Files\WindowsApps\OpenAI.Codex_26.602.3474.0_x64__2p2nqsd0c76g0\... into a normal destination directory fails with:
• code: UNKNOWN
• errno: -4094
• syscall: copyfile
• PowerShell Copy-Item also fails for the same protected files with:
• The specified file could not be encrypted.
• If the destination directory is first marked as encrypted (EFS), the same protected binaries can be copied successfully.

That seems consistent with the hypothesis in this issue that the failure is happening in the Store-package protected-file relocation path, not because the Computer Use helper binary is absent from the package.

Additional note:

• The user also checked another computer on June 5, 2026 and reported that it showed Computer Use unavailable as well, although I did not locally inspect that second machine. So this may include both a per-machine runtime problem and a broader rollout/account-side symptom, but the primary machine definitely reproduces the protected-file copy failure path described here.

Follow-up with a lower-destructive local workaround that restored bundled plugin availability on this Windows machine.

After confirming the protected-file relocation failures (copyfile / The specified file could not be encrypted.), I marked the actual Codex target directories as EFS-encrypted:

• %LOCALAPPDATA%\\OpenAI\\Codex\\bin
• %USERPROFILE%\\.codex\\.tmp\\bundled-marketplaces

After that, the same previously failing local copies from the Microsoft Store package into those real target paths succeeded. On the next app launch, the bundled plugins showed up in Plugin Marketplace again; after installing them there, Settings no longer showed Computer Use plugins unavailable, and the plugins were working normally.

This does not prove the full root cause beyond the local runtime path, but it does suggest that making the destination directories compatible with the WindowsApps protected/EFS source files can recover the bundled-plugin staging path without a full reinstall or manual marketplace remapping.

i am about tired of this bullshit, weeks passed and still no fix for this. can't use computer use without fucking around locally, can't elevate the sandbox because microsoft store permissions bullshit.
how are we as paying users getting cucked like this and wasting our money and quotas to fix openai's own mess which is not even a fix but a small bandaid that can be ruined with an update or a fresh install.

Additional reproduction with newer stable and Beta builds, plus results from several low-destructive workarounds.

Environment:

• Windows Home China / CoreCountrySpecific, build 26200.8457
• Stable Codex Store package: 26.623.5175.0
• Codex Beta Store package: 26.616.6631.0
• Chrome extension: 1.1.5, installed and enabled

Observed on both Stable and Beta:

• bundled_executable_relocation_failed for codex.exe and cua_node
• bundled_plugins_marketplace_resolve_failed / copyfile failures from WindowsApps
• Chrome native host com.openai.codexextension is never generated

Diagnostics and attempts:

• NTFS encryption capability is enabled and the EFS service is running; no EFS policy disables it.
• Store Repair, full uninstall/reinstall, and upgrading Stable did not help.
• The Beta package reproduces the same relocation failures.
• Byte-stream copying the official resources to user-owned destinations succeeded and SHA-256 verification passed: codex.exe, all 3,897 cua_node files, and all 808 bundled-marketplace files. The app still creates fresh staging directories and retries copyfile from WindowsApps on every launch.
• Re-registering a complete user-owned openai-bundled marketplace makes CLI plugin discovery work, but Desktop Chrome installation still cannot sync the native host.
• Move-AppxPackage to an online D: AppX volume completed without an error, but AppX event 744 reported that the package was already on the target volume and InstallLocation remained on C:.
• The EFS-encrypted-target workaround cannot be used on this edition: cipher /E returns The request is not supported.

The user-owned final runtime paths now contain verified codex.exe, node.exe, and node_repl.exe, but the app does not accept them as a replacement for its staging/relocation step.

This strongly suggests the Windows app needs a decrypted-destination or stream-copy fallback instead of relying exclusively on Node/Electron copyfile for Store-protected resources.

Follow-up after the Chrome plugin became installed and visible in Codex Desktop:

• A brand-new thread shows the Chrome plugin chip and accepts an @Chrome request.
• Logs report browser_use_availability_resolved available=true.
• Initialization then immediately fails with BrowserUseThreadConfig browser_use_setup_failed backend=node_repl phase=runtime-paths platform=win32 reason=node-repl-missing.
• The user runtime cache already contains hash-verified node.exe and node_repl.exe, copied from the official package, but Codex does not accept/use them because the bundled executable staging relocation still fails first.
• The Chrome Native Messaging Host manifest and HKCU registration are still not generated.

This confirms the extension UI/plugin selection layer is working; the remaining blocker is the bundled cua_node / node_repl relocation and registration path, before Chrome communication begins.

I have one more data point with an A/B comparison and a recovery path that worked on the same 26.623 build family.

Summary

On the affected machine, the root cause was not account/region/workspace policy. The failing part was the Store/MSIX package resource relocation from:

C:\Program Files\WindowsApps\OpenAI.Codex_...\app\resources\...

The bundled resources were marked as EFS / Application Protected. Codex then tried to relocate bundled plugins and helper runtimes with a normal copy path, which failed. As a result, Computer Use / Browser / Chrome bundled plugins were present in some places but not recognized by the app, node_repl was not injected, and Computer Use stayed unavailable.

Affected state

Symptoms included:

• Computer Use unavailable in Settings
• bundled plugin marketplace resolution failures
• node-repl-missing
• Computer Use helper path unavailable
• only the default MCP server loaded, no node_repl
• manual file prewarming did not make the app recognize the plugins

On the affected install, checking the bundled Computer Use plugin source under WindowsApps showed the source file was encrypted / Application Protected:

$pkg = (Get-AppxPackage OpenAI.Codex).InstallLocation
cipher /c "$pkg\app\resources\plugins\openai-bundled\plugins\computer-use\.codex-plugin\plugin.json"

The failing machine previously showed E plugin.json and Application Protected / encrypted behavior.

A normal Copy-Item from the WindowsApps source to a normal user-writable directory failed with:

The specified file could not be encrypted.

But a raw byte-stream copy, for example ReadAllBytes / WriteAllBytes, could read the same source and write an unencrypted copy successfully. That suggests the issue is not that the bytes are unreadable, but that the copy API/path preserves or re-applies encryption metadata in a way that fails outside the protected package boundary.

Working comparison

A known-good machine with the same account and region did not have encrypted bundled sources:

U plugin.json
New files added to this directory will not be encrypted.

fsutil behavior query disableencryption alone was not a useful discriminator, because EFS may be enabled at the system level while the Codex package files themselves are still unencrypted. The deciding signal was cipher /c on the actual Codex WindowsApps resource file: E vs U.

Recovery path that worked

After reinstalling Codex so that the Store package was installed on the system drive (C:), the same check on the affected machine changed to:

C:\Program Files\WindowsApps\OpenAI.Codex_26.623.9142.0_x64__2p2nqsd0c76g0\app\resources\plugins\openai-bundled\plugins\computer-use\.codex-plugin\

New files added to this directory will not be encrypted.

U plugin.json

After that:

• the official bundled marketplace rebuilt successfully
• computer-use@openai-bundled and browser@openai-bundled became available
• node_repl.exe was launched from the Codex-managed cua_node runtime
• SKY_CUA_NATIVE_PIPE_DIRECTORY was present
• Computer Use could connect to Windows and operate Notepad
• the in-app Browser plugin could connect successfully
• the fix remained stable across multiple Codex and system restarts

Suggested upstream fix

Please consider making bundled resource relocation resilient to EFS / Application Protected package files.

Possible fixes:

1. Detect when the WindowsApps bundled source file is encrypted / Application Protected and surface a specific diagnostic instead of a generic “plugin not found” / “Computer Use unavailable”.
2. Avoid relying only on fs.copyFile / normal copy semantics for bundled plugin and runtime relocation from WindowsApps.
3. Use a byte-stream copy fallback for bundled resources, or another Windows-safe copy path that does not require propagating EFS metadata to the destination.
4. If the package is installed on a non-system drive or in a Store/AppX state that marks resources as Application Protected, suggest reinstalling to the system drive or resetting the Store install location.
5. For Chrome, distinguish bundled marketplace/runtime relocation failures from the separate Chrome native host manifest generation failure.

The important practical observation is: once the WindowsApps source files became U instead of E, Codex’s normal bundled plugin path recovered and Computer Use / Browser became usable without manual plugin prewarming.

Subject

Windows Store Codex 26.707.3748.0: EFS-protected bundled resources fail with copyfile UNKNOWN, causing Browser removal and Computer Use native pipe failure

Environment

• OS: Windows
• Package: OpenAI.Codex
• Version: 26.707.3748.0
• Package identity: OpenAI.Codex_26.707.3748.0_x64__2p2nqsd0c76g0
• Signature kind: Store
• Package status: Ok
• Installation: Microsoft Store-managed package
• The package is physically stored under D:\WindowsApps and exposed through the standard C:\Program Files\WindowsApps path. Testing confirmed that the drive and junction are not the cause.

Summary

The main ChatGPT/Codex Desktop application works normally, including sign-in, conversation history, configuration, custom skills, and ordinary coding tasks.

However, the Desktop app cannot reliably copy its bundled plugins and Computer Use runtime from the WindowsApps package into user-writable directories. The packaged resource tree is EFS-encrypted, and the native CopyFile operation used by Desktop fails with UNKNOWN / errno -4094.

This causes:

• Browser to be removed during bundled marketplace reconciliation.
• Computer Use helper and transport paths to remain unavailable.
• The codex-computer-use-* native pipe not to be created.
• Bundled plugin state to become unstable across restarts.
• Existing complete user-side copies to be ignored instead of used as a fallback.

Confirmed root cause

The affected files have the Windows Encrypted attribute, and cipher /c reports them as EFS-encrypted.

The same source file was tested using two copy methods:

1. Read the source bytes and write them as a new normal file:

• Succeeded.
• All 4,982 bytes were read and written successfully.

1. Use native .NET File.Copy, comparable to the failing Desktop copy path:

• Failed with “The specified file could not be copied.”

The native copy also failed when using the real D:\WindowsApps\... source path directly, bypassing the C:\Program Files\WindowsApps junction. Therefore, the failure is not caused by the junction or by copying between drives.

The evidence indicates that EFS transparent reads succeed, while the native copy operation fails when attempting to preserve or process the encrypted file state.

Desktop log evidence

During the latest launch, Desktop repeatedly reported:

plugin_marketplace_folder_write_failed
errorCode=UNKNOWN
UNKNOWN: unknown error, copyfile

Affected files included:

plugins\chrome\.codex-plugin\backend-specific-skill.md
plugins\latex\.codex-plugin\plugin.json

Each failure was followed by:

bundled_plugins_marketplace_resolve_failed

Browser was then removed:

bundled_plugin_uninstall_requested
pluginId=browser@openai-bundled
reason=not_in_bundled_marketplace_plugin_names

Computer Use repeatedly reported:

computer-use native pipe helper paths unavailable
missingHelperPath=true
missingTransportModulePath=true

and:

computer_use_native_pipe_thread_config_skipped
reason=not-ready

The same launch also reported native copy failures while relocating:

• codex.exe
• rg.exe
• cua_node

Existing user-side files are already complete

The active user-side bundled marketplace contains all seven current plugins:

• sites
• browser
• chrome
• computer-use
• latex
• deep-research
• visualize

File-by-file comparison against the Store package found no missing official plugin files. SHA-256 values match, except for one intentional local Computer Use compatibility overlay.

The Computer Use runtime is also already complete:

| Check | Store package | User runtime |
|---|---:|---:|
| File count | 3,558 | 3,558 |
| Missing files | — | 0 |
| Extra files | — | 0 |
| manifest.json | Matching SHA-256 | Matching SHA-256 |
| node.exe | Matching SHA-256 | Matching SHA-256 |
| node_repl.exe | Matching SHA-256 | Matching SHA-256 |
| @oai/sky/package.json | Matching SHA-256 | Matching SHA-256 |

The user runtime matches the current Store package:

Node: 24.14.0
node_repl: 20260707.2
CUA runtime: 0.0.3/20260708050802-66a5641b5362-pr-1103797

Despite these complete existing copies, Desktop performs a new relocation and marketplace staging operation on every launch. When the new copy fails, Desktop does not fall back to the verified existing runtime or the last complete marketplace.

Repeated staging failures

Approximately 20 abandoned directories currently exist with names such as:

openai-bundled.staging-<GUID>

They contain incomplete directory structures for different subsets of plugins, but no complete copied marketplace. This is consistent with repeated startup synchronization attempts failing at different points.

A complete seven-plugin marketplace exists beside them, but Desktop still starts another staging copy and bases reconciliation on the failed result.

Current user-visible impact

Confirmed:

• Computer Use native pipe is unavailable.
• Computer Use cannot reliably control Windows applications.
• sky.list_apps() and real screen access cannot be validated through Desktop.
• Browser cache is missing.
• Browser may appear uninstalled.
• Browser was explicitly removed by the latest marketplace reconciliation.
• Plugin state may change after restarting Desktop.

Currently healthy:

• Main ChatGPT/Codex Desktop UI
• Store package signature and registration
• Sign-in
• Conversation history
• Configuration
• Custom skills
• Ordinary coding and chat tasks
• Existing Chrome plugin cache
• Chrome native messaging host path

Chrome’s cache and native host point to a stable versioned directory, but a complete real-browser user journey has not yet been validated.

No direct failure has been confirmed for sites, latex, deep-research, or visualize, although they share the same unreliable bundled marketplace synchronization path.

Expected behavior

Desktop should be able to initialize bundled plugins and Computer Use from a Store-installed package whose resources are EFS-protected.

A failed marketplace update should not remove previously valid plugins.

If a verified complete runtime or marketplace already exists, Desktop should preserve and reuse it when refreshing the packaged copy fails.

Suggested fixes

Any of the following would address the problem without requiring users to modify protected WindowsApps files:

1. On Windows, fall back from native copyfile/fs.cp to a byte-stream copy when the source is readable but native copying fails because of EFS.

1. If bundled runtime relocation fails, validate and reuse the existing complete versioned runtime directory.

1. If bundled marketplace staging fails, preserve the last known-good complete marketplace instead of reconciling against the incomplete staging result.

1. Do not uninstall bundled plugins based on a marketplace plugin-name list produced by a failed or incomplete staging operation.

1. Add explicit logging that distinguishes:

• source read failure;
• EFS/native-copy failure;
• incomplete staging;
• fallback to an existing runtime or marketplace.

Important constraints

I would like to keep:

• The official Microsoft Store signature
• Normal Store updates
• Existing sign-in and conversation history
• Existing configuration and custom skills

I do not want to:

• Decrypt or modify the WindowsApps package tree
• Change WindowsApps ownership or ACLs
• Patch app.asar
• Repackage or re-sign the MSIX
• Replace the Store package with a developer-signed build

A fix in the official Desktop copy/fallback logic appears necessary for a durable solution.

Adding another manifestation of the same root cause, plus diagnostic data and a verified workaround.

Environment

• Codex Desktop: 26.715.3651.0 (Microsoft Store, SignatureKind: Store)
• OS: Windows 11 Pro 10.0.26200 (same build family as the reports above)

New manifestation: pet creation is also broken

Clicking Settings → Pets → Create shows "Cannot start creating pet". The desktop log shows the same copyfile failure while installing the hatch-pet recommended skill:

warning [electron-fetch-handler] Failed to install recommended skill
error="UNKNOWN: unknown error, copyfile
'C:\Program Files\WindowsApps\OpenAI.Codex_26.715.3651.0_x64__2p2nqsd0c76g0\app\resources\skills\skills\.curated\hatch-pet\agents\openai.yaml'
-> 'C:\Users\<user>\.codex\skills\hatch-pet\agents\openai.yaml'"

The installer wipes ~/.codex/skills/hatch-pet and re-copies it on every launch and every Create click, so it always leaves an empty skeleton (just an empty agents\ dir). Manually pre-placing byte-identical files does not help — they are wiped and the copy fails again. bundled_executable_relocation_failed ... during copy_directory (cua_node relocation) appears in the same logs, consistent with #32589.

Additional diagnostics (things that do NOT work)

• Package files have the Encrypted attribute; cipher /c reports "Compatibility Level: Application Protected".
• Plain user EFS on the same volume works fine (cipher /e on a new temp file succeeds), so the machine's EFS itself is healthy.
• A plain Copy-Item of a package file fails with "The specified file could not be encrypted" at the destination — CopyFileW tries to replicate the protection context and can't.
• cipher /d on package files fails with "The parameter is incorrect" even from an elevated shell after takeown + granting Full Control — this is not standard user-cert EFS.
• With ownership and Full Control, deleting a package file succeeds but writing a new file back into the package directory is denied, so the write block is enforced below the ACL layer.
• Uninstalling and reinstalling from the Store redeploys the package with the same encrypted attributes — reinstall does not fix it.

Verified workaround (byte-stream copy works end to end)

Byte-stream reads of the "encrypted" files succeed everywhere. I stream-copied the entire app directory (9,494 files, ~1.8 GB) out of WindowsApps into a plain directory:

• 0 copy failures, 0 files with the Encrypted attribute in the clone;
• running ChatGPT.exe from the cloned directory: the hatch-pet skill installs successfully and pet creation works immediately.

This directly supports the fix proposed in #32589: falling back to a byte-stream copy (fs.readFile + fs.writeFile) when native copyfile fails but the source is readable would resolve every affected feature (skills, bundled plugins marketplace, cua_node relocation).

Adding another confirmed reproduction on newer Codex Desktop builds, including measured performance impact and a verified A/B workaround.

Environment

• Codex Desktop: 26.715.7063.0, then 26.715.8383.0
• Microsoft Store install; SignatureKind: Store; package status Ok
• Windows 11 Pro x64, build 26200.8875
• Bundled Codex CLI: 0.145.0-alpha.27

All usernames, package identity suffixes, request/conversation IDs, pipe and staging GUIDs, workspace paths, and log filenames are redacted.

Performance impact

The slowdown began after a Desktop update. Startup plus plugin/app discovery became noticeably sluggish while bundled resource staging repeatedly failed.

Measured desktop-log durations:

• app/list: up to 19054 ms
• plugin/list: up to 7874 ms
• several other app/list calls took approximately 13–15 seconds

These timings are correlation data; I cannot prove every slow app/list call is caused only by relocation.

Failure chain

Representative sanitized runtime relocation entry:

warning bundled_executable_relocation_failed
errorCode=UNKNOWN
errorMessage="Bundled executable relocation failed during copy_directory"
executableName=node.exe
failedExecutableName=node.exe
operation=copy_directory
sourceKind=windowsapps
sourcePath="C:\Program Files\WindowsApps\OpenAI.Codex_<version>_x64__<package-id>\app\resources\cua_node"
originalError={
  "errno": -4094,
  "code": "UNKNOWN",
  "syscall": "copyfile",
  "path": "...\app\resources\cua_node\bin\CHANGELOG.md",
  "dest": "%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\.staging-<id>\bin\CHANGELOG.md"
}

Bundled marketplace staging failed the same way:

[BundledPluginsMarketplace] plugin_marketplace_folder_write_failed
errorCode=UNKNOWN
folderWritePhase=copy_plugins
errorMessage="UNKNOWN: unknown error, copyfile
'C:\Program Files\WindowsApps\OpenAI.Codex_<version>_x64__<package-id>\app\resources\plugins\openai-bundled\...'
-> '%USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled.staging-<id>\...'"

The subsequent failure chain included:

[BundledPluginsMarketplace] bundled_plugins_marketplace_resolve_failed
[computer-use-native-pipe] computer-use native pipe helper paths unavailable
missingHelperPath=true
missingTransportModulePath=true

The affected Store resources had the Windows Encrypted attribute, and cipher /c reported:

Compatibility Level:
  Application Protected

Verified A/B workaround

I copied the official CLI and bundled plugin resources into stable, user-owned, unencrypted directories and selected them through:

CODEX_CLI_PATH=%LOCALAPPDATA%\OpenAI\Codex\overrides\<cli-version>\codex.exe
CODEX_ELECTRON_BUNDLED_PLUGINS_RESOURCES_PATH=%LOCALAPPDATA%\OpenAI\Codex\overrides\bundled-resources-<app-version>

After a full Desktop restart, the latest startup log showed:

• zero bundled_executable_relocation_failed entries
• no WindowsApps copyfile failure during bundled resource staging
• successful bundled marketplace writes from the user-owned resource tree
• Computer Use native pipe reaching startup ready
• bundled plugins available again
• visibly improved responsiveness

Representative sanitized success entries:

[computer-use-native-pipe] computer-use native pipe startup ready
[BundledPluginsMarketplace] plugin_marketplace_folder_write_succeeded
sourceMarketplaceRoot=%LOCALAPPDATA%\OpenAI\Codex\overrides\bundled-resources-<app-version>\plugins\openai-bundled

One later app/list request still took about 13.9 s, so a separate app-discovery performance issue may remain. The A/B result does, however, eliminate the Application Protected relocation failure chain.

A normal Store update did not fix the condition: it installed another Application Protected resource tree under a new versioned WindowsApps path, requiring the version-specific user-owned copy to be refreshed.

Suggested product behavior

1. Fall back to byte-stream copying when native copyfile fails but the protected source is readable.
2. Validate and reuse a complete last-known-good relocated runtime/CLI.
3. Preserve the last working bundled marketplace if new staging fails.
4. Do not disable bundled plugins based on an incomplete staging result.
5. Avoid repeating the failing relocation during startup and plugin/app listing.
6. Report an Application Protected/EFS-specific diagnostic instead of generic UNKNOWN.

This confirms the issue remains reproducible in the 26.715 build family, including 26.715.8383.0.

I am seeing the same bundled-plugin problem on the Windows Store build, even after restoring the missing plugin and runtime files.

Environment

• Windows 11 Home, build 26200, 64-bit
• Windows Microsoft Store Codex 26.721.4979.0 (x64)
• ChatGPT Plus
• Bundled Browser, Chrome, and Computer Use plugins 26.721.41059

Current state

• codex plugin list reports Browser, Chrome, and Computer Use as installed and enabled.
• The bundled plugin manifests and runtime files are present in user-writable locations.
• The Chrome native host works.
• The in-app Browser still reports that browser@openai-bundled is not loaded.
• Computer Use reports that the dedicated Windows control session is not exposed.
• The active session does not expose mcp__node_repl__js.
• codex mcp list does not show the expected node_repl server.

Troubleshooting already performed

• Restarted Codex.
• Created new conversations.
• Reinstalled and re-enabled the bundled plugins.
• Restored the plugin cache and runtime files after the WindowsApps copy failure.
• Switched the marketplace source back to the packaged Store bundle.
• Verified the Node, node_repl, Sky helper, and helper transport files again.

The plugin instructions are visible, but the callable Browser and Computer Use control surface is missing from the active session. This seems related to #25247, where the trusted native pipe or nodeRepl.nativePipe is not injected into the session.

Temporary workaround

The issue can be partially worked around by copying the bundled plugin files and the cua_node runtime from the Store package into user-writable locations. The copy uses data, attributes, and timestamps only, which avoids the WindowsApps/EFS copy failure.

Close Codex before running this:

<details>
<summary>Restore the bundled plugin files and runtime</summary>

~~~powershell
$ErrorActionPreference = "Stop"

$pkg = Get-AppxPackage -Name OpenAI.Codex
if (-not $pkg) {
throw "OpenAI.Codex Store package was not found."
}

$resources = Join-Path $pkg.InstallLocation "app\resources"
$codexHome = if ($env:CODEX_HOME) {
$env:CODEX_HOME
} else {
Join-Path $env:USERPROFILE ".codex"
}

$pluginSource = Join-Path $resources "plugins\openai-bundled\plugins"
$pluginCache = Join-Path $codexHome "plugins\cache\openai-bundled"
$runtimeSource = Join-Path $resources "cua_node"
$runtimeTarget = Join-Path $env:LOCALAPPDATA "OpenAI\Codex\runtimes\cua_node"

New-Item -ItemType Directory -Force -Path $pluginCache, $runtimeTarget | Out-Null

& robocopy $pluginSource $pluginCache /E /COPY:DAT /DCOPY:DAT /R:1 /W:1
if ($LASTEXITCODE -gt 7) {
throw "Plugin copy failed with robocopy exit code $LASTEXITCODE."
}

& robocopy $runtimeSource $runtimeTarget /E /COPY:DAT /DCOPY:DAT /R:1 /W:1
if ($LASTEXITCODE -gt 7) {
throw "Runtime copy failed with robocopy exit code $LASTEXITCODE."
}
~~~

</details>

Chrome then started working after registering the restored native host manifest and its user-level registry entry:

<details>
<summary>Register the Chrome native host</summary>

~~~powershell
$chromeRoot = Join-Path $pluginCache "chrome"
$versionDir = Get-ChildItem $chromeRoot -Directory |
Where-Object { $_.Name -ne "latest" } |
Sort-Object LastWriteTime -Descending |
Select-Object -First 1

$pluginDir = $versionDir.FullName
$extensionId = (
Get-Content (Join-Path $pluginDir "scripts\extension-id.json") -Raw |
ConvertFrom-Json
).extensionId

$hostExe = Join-Path $pluginDir "extension-host\windows\x64\extension-host.exe"
$manifestPath = Join-Path $env:LOCALAPPDATA "OpenAI\extension\com.openai.codexextension.json"

New-Item -ItemType Directory -Force -Path (Split-Path $manifestPath) | Out-Null

$manifest = [ordered]@{
allowed_origins = @("chrome-extension://$extensionId/")
description = "ChatGPT Chrome native messaging host"
name = "com.openai.codexextension"
path = $hostExe
type = "stdio"
}

$json = $manifest | ConvertTo-Json -Depth 3
[IO.File]::WriteAllText(
$manifestPath,
$json,
[Text.UTF8Encoding]::new($false)
)

reg.exe add "HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension" /ve /t REG_SZ /d $manifestPath /f
~~~

</details>

This restored the Chrome extension-to-app connection.

Remaining issue

Browser and Computer Use still fail because the active session does not expose node_repl or the trusted native pipe. The workaround restores the local files and Chrome native host, but it does not fix the session-level tool registration.

Could you confirm whether the Windows Store build needs a separate fix for registering the node_repl server and trusted native pipe?

Adding a confirmed reproduction and workaround on a newer build.

Environment

• Codex/ChatGPT Windows app: 26.727.6591.0
• Windows 11 x64
• Microsoft Store install
• Windows “New apps will save to” was set to a secondary volume, D:

Reproduction and failed recovery attempts

With the Store app installed on D:, the app stack resolved through:
D:\WindowsApps\OpenAI.Codex_26.727.6591.0_x64__2p2nqsd0c76g0\...

Fresh startup logs repeatedly contained:

• bundled_executable_relocation_failed (UNKNOWN, errno=-4094, syscall=copyfile) for rg.exe, codex.exe, and cua_node
• bundled_plugins_marketplace_resolve_failed
• plugin_marketplace_folder_write_failed
• computer-use native pipe helper paths unavailable missingHelperPath=true missingTransportModulePath=true

Repair, Reset, and a Store-app uninstall/reinstall while “New apps will save to” remained D: did not help. I did not delete the per-user .codex directory. statsig-disabled did not appear in either the failing or successful fresh logs.

Confirmed workaround

1. Windows Settings → System → Storage → Advanced storage settings → Where new content is saved
2. Change only “New apps will save to” from D: to C:
3. Uninstall the Store app
4. Reinstall it from Microsoft Store

After reinstalling on C:, the executable path was:
C:\Program Files\WindowsApps\OpenAI.Codex_26.727.6591.0_x64__2p2nqsd0c76g0\app\resources\codex.exe

A fresh startup log then showed:

• bundled_executable_relocation_failed: 0
• bundled_plugins_marketplace_resolve_failed: 0
• plugin_marketplace_folder_write_failed: 0
• copyfile: 0
• missingHelperPath=true: 0
• [computer-use-native-pipe] computer-use native pipe startup ready
• bundled_plugins_runtime_marketplace_written pluginCount=6 pluginNames=["sites","browser","chrome","computer-use","latex","visualize"]
• bundled_plugins_reconcile_completed

The UI immediately showed Computer Use and Chrome again.

This strongly suggests the failure is tied to the Microsoft Store package being installed on a non-system app volume (D:\WindowsApps), rather than Statsig, account rollout, or stale per-user plugin state. It may be worth either blocking unsupported secondary-volume installs, copying package resources without propagating Application Protected/EFS attributes, or surfacing a targeted diagnostic and workaround.

Follow-up: this is now resolved, and a strict A/B comparison narrows the trigger to the Store package's AppX deployment volume / Application Protected state.

Environment

• Codex/ChatGPT Windows app: 26.727.6591.0
• Windows 11 Pro 25H2, build 26200.8875
• Microsoft Store install

Affected machine

• Before recovery, Get-AppxDefaultVolume pointed to a secondary non-system app volume: D:\WindowsApps, IsSystemVolume=False.
• A bundled Computer Use manifest had the Encrypted attribute.
• cipher /c reported E and Compatibility Level: Application Protected.
• Copying that readable file outside the package with Copy-Item failed with 0x80071770: The specified file could not be encrypted.
• The current-user EFS certificate count was 0.
• Runtime logs showed bundled_executable_relocation_failed, plugin_marketplace_folder_write_failed, bundled_plugins_marketplace_resolve_failed, and Computer Use startup with missingHelperPath=true missingTransportModulePath=true.
• Repair/reset, uninstall/reinstall, and upgrading Windows Home China to Pro did not help while the default AppX volume condition remained.

Working control machine

A second machine used the same Codex version and same Windows build, but its default AppX deployment volume was the system volume:

C:\Program Files\WindowsApps, IsSystemVolume=True.

On that machine, the same bundled manifest had only the Archive attribute, and cipher /c reported U (unencrypted). Computer Use / Any App worked normally. Its current-user EFS certificate count was also 0.

Confirmed recovery

Run elevated PowerShell:

$c = Get-AppxVolume |
  Where-Object IsSystemVolume |
  Select-Object -First 1

Set-AppxDefaultVolume -Volume $c

Get-AppxDefaultVolume |
  Format-List PackageStorePath, IsSystemVolume

Verify the result is C:\Program Files\WindowsApps and IsSystemVolume=True, then fully uninstall the Store app and reinstall it. After reinstalling, Computer Use / Any App appeared and works.

This also rules out Chinese system language, Home-vs-Pro edition, account rollout, and a missing user EFS certificate as the primary cause in this reproduction. The decisive difference was the AppX volume / package-resource protection state.

Suggested product fix

• Avoid metadata-preserving fs.copyFile semantics for readable Application Protected bundled resources; fall back to byte-stream copying into a user-owned unencrypted destination.
• Or block/validate unsupported secondary-volume Store installs.
• At minimum, surface a targeted Application Protected / AppX volume diagnostic instead of generic UNKNOWN copyfile errors, with instructions to switch the default app volume to the system drive before reinstalling.

No usernames, account identifiers, device IDs, or user-profile paths are included above.

我是 WinBridge Recovery 的维护者。这个 EFS / Application Protected 场景和我最近在 Windows Store Codex 上研究的故障链高度重合，不过我想把当前状态说得保守一点：我还不认为这个问题已经被稳定解决。

WinBridge v3.1.1 目前已经不依赖 Node copyfile / 普通 File.Copy 来构建用户侧官方资源镜像，而是使用 FileStream 做 byte-stream copy，并对 source/destination 做 SHA-256 校验；staging 校验失败时不会切换到残缺 marketplace/cache，也不会修改 WindowsApps 的 ACL、ownership 或加密状态。

这和本 issue 里“源文件可读，但普通复制在 Application Protected/EFS 文件上失败”的现象是吻合的，因此我已经把它放进项目的长期研究项：

• 明确识别 Application Protected / Archive, Encrypted 属性；
• 单独分类 copyfile UNKNOWN / errno -4094 / Windows error 6000；
• 对多个真实 Microsoft Store Codex build 重复验证 byte-stream copy；
• copy 后继续做 SHA-256，并计划补关键 EXE/DLL 的 Authenticode 验证；
• 只有跨多个 Store 更新和 Windows build 都稳定后，才会从 Experimental 升级成默认支持。

所以如果这里的根因确实是“包内文件可读、native copy 失败”，WinBridge 的当前复制模型是一个有希望的非破坏性 workaround；但我暂时不会声称它对所有 EFS/Application Protected 机器都能 100% 修复。项目只读取目标机器上已安装的官方包并恢复用户侧状态，不重新分发官方文件，也不绕过 WindowsApps/安全策略。

这个 issue 里后续如果有人能提供不同 Store build / Windows build 上 byte-stream 成功或失败的结果，对确认这个方案是否真正可泛化会很有价值。

Independent reproduction on a newer Codex Desktop build.

Environment

• Codex Desktop: 26.818.4152.0
• OS: Windows 10 Pro x64, build 19045.6466
• Install type: packaged Windows app (OpenAI.Codex_26.818.4152.0_x64__2p2nqsd0c76g0)
• Chrome extension: installed and enabled (hehggadaopoacecdllhhajmbjkdcmajg, version 1.2.27268.51612_0)

Observed behavior

Codex repeatedly fails while copying the bundled marketplace from WindowsApps into the user staging directory:

[BundledPluginsMarketplace] plugin_marketplace_folder_write_failed
errorCode=UNKNOWN
errorMessage="UNKNOWN: unknown error, copyfile 'C:\Program Files\WindowsApps\OpenAI.Codex_26.818.4152.0_x64__2p2nqsd0c76g0\app\resources\plugins\openai-bundled\plugins\sites\.app.json' -> '%USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled.staging-...\plugins\sites\.app.json'"
folderWritePhase=copy_plugins

The same failure repeats on every bundled-marketplace reconciliation attempt. A direct PowerShell Copy-Item test against packaged plugin files reports that the specified file cannot be encrypted; packaging the source into an archive and extracting it outside WindowsApps succeeds.

Chrome itself appears healthy: it is running, the extension is installed/enabled, no HKCU/HKLM Chrome enterprise policies are present, and the current user has full control over the relevant parent directory and registry key. However, Codex never creates:

%LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json
HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension
extension-host-config.json

Therefore @Chrome cannot connect and the Node REPL/browser execution interface is not exposed to the thread.

Attempts already made

• Uninstall/reinstall chrome@openai-bundled
• Install an extracted local-source copy as a personal plugin
• Re-register the Windows app package with Add-AppxPackage -Register
• Restart Codex and Chrome

The issue persists. This suggests the WindowsApps protected/encrypted-file copy failure still affects Codex Desktop 26.818.4152.0 and prevents the Chrome native-host setup path from completing.

Confirmed on Codex Desktop 26.820.7780.0.

The app was installed on a non-system Microsoft Store app volume under D:\WindowsApps. The Desktop logs repeatedly showed:

• bundled_executable_relocation_failed
• plugin_marketplace_folder_write_failed
• bundled_plugins_marketplace_resolve_failed
• Computer Use helper paths unavailable with missingHelperPath=true and missingTransportModulePath=true

The following steps completely resolved the issue for me:

1. Open Windows Settings → System → Storage → Advanced storage settings → Where new content is saved.
2. Change New apps will save to to the system drive (C:).
3. Uninstall Codex Desktop.
4. Reinstall it from Microsoft Store.
5. Confirm that the new package is installed under C:\Program Files\WindowsApps.

After reinstalling on C:, the bundled plugins, Chrome integration, and Computer Use became available and worked normally. My existing .codex settings and conversation history were preserved. I did not delete .codex, modify WindowsApps permissions, or change the package files.

This may be worth detecting in Codex Desktop: if the app is installed on a non-system AppX volume, show a targeted warning explaining that the user should change the Microsoft Store default app volume to the system drive and reinstall.