[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).