Computer Use unavailable on Windows: Application Protected files fail to copy from WindowsApps

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

• #34541

Powered by Codex Action

Reproduced on another Windows 11 Microsoft Store installation and this also causes noticeably slow app startup.

Environment:

• Store package: OpenAI.Codex 26.715.9079.0
• Windows 11 x64
• Install method: Microsoft Store / MSIX

Observed startup timing from the desktop log:

• app launch -> ready-to-show: ~9.6 s
• app launch -> renderer routes mounted: ~15.4 s
• Store update check: ~2.0 s
• bundled executable relocation retries: ~4.0 s before the app server can spawn
• an additional Git-origins scan completed in ~6.9 s after the window was shown

The relocation failures repeatedly include rg.exe, codex.exe, and the cua_node runtime:

bundled_executable_relocation_failed
errorCode=UNKNOWN
originalError={ errno: -4094, code: UNKNOWN, syscall: copyfile }
sourceKind=windowsapps

Independent reproduction (redacted paths): the package source exists, but copying ...\\WindowsApps\\OpenAI.Codex_...\\app\\resources\\rg.exe to an ordinary user-writable directory fails with:

The specified file could not be encrypted.
HRESULT: -2147018896

The destination cache directories are writable, so this does not appear to be ordinary user-cache permissions. No active reconnect/network failure was present in this startup. This extends the impact beyond Computer Use: the repeated relocation attempts materially delay first usable UI.

I reproduced this issue and found a working workaround on my machine that may help narrow the root cause.

Environment

• Windows 11 x64 / 10.0.26200.8875
• Edition: CoreCountrySpecific
• Codex package: OpenAI.Codex_26.803.10989.0_x64__2p2nqsd0c76g0
• Microsoft Store: 22606.1401.13.0
• App Installer: 1.29.280.0

Before the workaround:

Computer Use plugin exists = True
CUA source exists          = True
CUA SOURCE FILES           = 3452

cipher /c node_repl.exe:
E node_repl.exe
  Compatibility Level:
    Application Protected

CUA DEST EXISTS            = True
CUA DEST FILES             = 0
node_repl.exe exists          = False
codex-computer-use.exe exists = False
helper_transport.js exists    = False

The bundled marketplace copy did contain computer-use, but the CUA runtime relocation did not complete and no Computer Use backend process was present.

Important AppxVolume finding

The surprising part was that Get-AppxPackage OpenAI.Codex reported an InstallLocation shaped like:

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

but the package was actually registered on my non-system D: AppxVolume.

$cVol = Get-AppxVolume -Path C:\
$dVol = Get-AppxVolume -Path D:\

Get-AppxPackage -Volume $cVol | Where-Object Name -eq 'OpenAI.Codex'
# no result

Get-AppxPackage -Volume $dVol | Where-Object Name -eq 'OpenAI.Codex'
# OpenAI.Codex returned here

The AppX deployment log also explicitly showed target volume D:.

My volumes were:

C:\Program Files\WindowsApps   IsSystemVolume=True
D:\WindowsApps                 IsSystemVolume=False

A control machine with the same Windows build, same Store/App Installer versions, and a working Computer Use installation had Codex on the system AppxVolume and its packaged node_repl.exe was reported as U (unencrypted).

Workaround that restored Computer Use

I fully exited Codex and moved the already-installed package to the system AppxVolume using the built-in Appx cmdlet:

$pkg  = Get-AppxPackage OpenAI.Codex
$cVol = Get-AppxVolume -Path C:\
Move-AppxPackage -Package $pkg.PackageFullName -Volume $cVol

Then I verified:

Get-AppxPackage -Volume (Get-AppxVolume -Path C:\) |
  Where-Object Name -eq 'OpenAI.Codex'
# package present

Get-AppxPackage -Volume (Get-AppxVolume -Path D:\) |
  Where-Object Name -eq 'OpenAI.Codex'
# no result

After reopening Codex, Computer Use immediately appeared in the Plugins UI and could be installed. I then confirmed that it actually worked by using Computer Use to open Notepad and type text.

So on this machine, moving Codex from a non-system AppxVolume to the system AppxVolume was sufficient to restore Computer Use, even though the ordinary InstallLocation string had previously looked like a C:\WindowsApps path.

This may be useful as both a workaround and a diagnostic clue: InstallLocation alone did not reveal the actual AppxVolume association. Get-AppxPackage -Volume ... and the AppX deployment log did.

I did not modify WindowsApps ACLs, ownership, EFS state, package files, registry values, or app.asar.

I published the AppxVolume diagnostic/workaround from my reproduced case as a small public repository:

https://github.com/Yajuju207/codex-windows-appxvolume-fix

It includes:

• diagnose.ps1: read-only checks for the actual AppxVolume association, packaged cua_node state, runtime file count, helper files, and recent AppX deployment evidence.
• fix-appxvolume.ps1: guarded Move-AppxPackage workaround; dry-run by default and only performs the move with -Apply.
• docs/case-study.md: sanitized before/after evidence from the failing non-system AppxVolume state and the working system AppxVolume state.

The repository deliberately does not modify WindowsApps ACLs/ownership, decrypt package files, patch app.asar, or redistribute OpenAI binaries.

For my machine, moving Codex from the non-system AppxVolume to the system AppxVolume was sufficient for Computer Use to reappear in Plugins and work successfully.

I maintain WinBridge Recovery, an independent Windows recovery tool for Codex Desktop: https://github.com/zemeng5208/winbridge-recovery

This issue is very close to one of the local failure classes the project is designed to diagnose. In v3.1.1, WinBridge already resolves the currently installed Store package, builds a user-writable verified resource mirror, uses byte-stream FileStream copying with SHA-256 verification, and checks the bundled marketplace / plugin cache / latest / CUA runtime / Native Host layers before deciding whether to repair anything.

The Application Protected / EFS path is still explicitly Experimental in the project; I do not consider it a guaranteed fix yet. The newer AppxVolume finding in this thread is particularly useful: InstallLocation alone is not sufficient, so I am treating the actual AppxVolume association and protection state as an important diagnostic signal rather than assuming every C:\Program Files\WindowsApps\... path is equivalent.

For machines where the failure is local relocation/cache/marketplace drift, WinBridge may be useful for diagnosis and safe staged recovery/rollback from the official package already installed on that machine. It does not modify WindowsApps ACLs/ownership, decrypt or patch the Store package, and it will not fix an upstream Computer Use runtime bug once the local runtime has been provisioned correctly.

Additional physical-volume A/B evidence from an affected Windows 11 machine:

• Get-AppxPackage reported the usual C:\Program Files\WindowsApps\OpenAI.Codex_<version>... install path, but that package directory was a junction whose physical target was D:\WindowsApps\OpenAI.Codex_<version>....
• The Codex runtime/plugin destinations remained on C: under %LOCALAPPDATA%\OpenAI\Codex and %USERPROFILE%\.codex.
• The failing copies had the same errno=-4094, code=UNKNOWN, syscall=copyfile, sourceKind=windowsapps signature described here. At the time, the Desktop package was on a 26.803 build while local bundled plugin/runtime material still contained 26.623 artifacts.
• After moving the Store package back to the system AppX volume, the package directory became a physical C: directory rather than a junction to D:. The next Store update (26.810.6296.0 -> 26.810.7004.0) stayed physically on C: and the original cross-volume -4094 signature was no longer the active failure.

This does not prove that all D-drive installations fail, or that cross-volume placement is required for the protected-file bug. It does confirm that a non-system AppX volume was a trigger in at least one reproducible environment and that returning the package to the system volume removed that trigger.

I documented the complete two-layer postmortem (protected-file relocation plus a separate persisted-marketplace conflict exposed by the next Store update) here:

https://gist.github.com/MickeyWzt/416bd69fa28b59c65aaec37aed9b34d1

Reproduced on a newer Windows build, with the same protected-file/runtime relocation pattern and a much larger impact on startup responsiveness.

Environment

• ChatGPT/Codex Microsoft Store package: 26.818.3698.0
• About dialog: 26.818.31338 (released Aug 21, 2026)
• Windows 11 Home Single Language 25H2, build 26200.9168
• Personal/unmanaged device

AppxVolume / cross-volume correlation

My packaged Codex resources are physically being accessed from D:\WindowsApps\OpenAI.Codex_..., while the per-user runtime destination is on C: under:

C:\Users\<user>\AppData\Local\OpenAI\Codex\runtimes\cua_node

That appears consistent with the non-system AppxVolume / cross-volume pattern reported above in this thread.

User-visible impact

On this build, the problem is not limited to Computer Use being unavailable. The entire ChatGPT desktop app repeatedly becomes Not Responding during startup and can take roughly 40 minutes to become usable. Restarting often re-enters the same behavior.

Windows Error Reporting logged:

Event Name: AppHangTransient
Process: ChatGPT.exe
Timestamp: 2026-08-21 19:41:01 UTC

WinDbg evidence

I captured a full user-mode dump while ChatGPT.exe was actively hung. !analyze -hang reported:

FAILURE_PROBLEM_CLASS: BlockedOn_FileIO
IMAGE_NAME: chrome.dll

Relevant stack:

ntdll!NtCreateFile
KERNELBASE!BaseCopyStream
KERNELBASE!BasepCopyFileExW
KERNELBASE!CopyFileExW
KERNELBASE!CopyFileW
chrome!uv_fs_open
chrome!uv_fs_copyfile
...
chrome!ChromeMain
ChatGPT

Inspecting the NtCreateFile parameters identified the blocked target as:

C:\Users\<user>\AppData\Local\OpenAI\Codex\runtimes\cua_node\
.staging-dd584937042db7da-<random>\bin\corepack

Procmon reproduction

Sysinternals Process Monitor independently captured the same operation:

Process: ChatGPT.exe
Operation: CreateFile
Result: ACCESS DENIED
Duration: ~20.0015 seconds
Disposition: OverwriteIf

The target was the same .staging-...\bin\corepack path. Multiple attempts showed the same ~20 second delay before ACCESS DENIED.

I then renamed the existing local cua_node directory and let the app rebuild it from scratch. The behavior reproduced cleanly:

1. a new .staging-dd584937042db7da-<random> directory was created;
2. bin\corepack appeared at 0 KB;
3. the partial staging contents were removed;
4. another .staging-* attempt was created later with the same runtime ID and a different random suffix.

Encryption / independent copy test

cipher /c reports the bundled WindowsApps source corepack as encrypted:

E corepack

I also tested an elevated manual copy using:

xcopy /G /Y "<WindowsApps Codex package>\app\resources\cua_node\bin\corepack" "%TEMP%\codex-efs-test\"

Unlike the workaround reported in the original issue, /G does not succeed on this machine. It stalls for roughly two minutes, exits without the normal 1 File(s) copied confirmation, and no destination corepack is created.

So on 26.818.3698.0, this still looks closely related to the protected/Application Protected runtime relocation issue, with a strong additional correlation to a non-system D: AppxVolume and with the impact now extending to repeated full-app startup hangs.

I have preserved the full WinDbg dump, Procmon .PML, WER details, and sanitized screenshots if maintainers need additional diagnostics.

---

Update: Confirmed mitigation and before/after results are documented here: https://github.com/openai/codex/issues/34764#issuecomment-5379844462

Confirmed mitigation / before-after result

Following the earlier findings in this thread, I moved only the OpenAI.Codex package from the non-system D: AppxVolume to the system C: AppxVolume using Windows' built-in Move-AppxPackage.

Before the move

• OpenAI.Codex was registered on D:\WindowsApps (IsSystemVolume=False).
• The package files on D: were marked encrypted/protected.
• ChatGPT Desktop routinely took 25–50+ minutes to start, frequently became Not Responding, or showed the crash screen.
• WinDbg showed the hang inside CopyFileW / uv_fs_copyfile.
• Procmon captured repeated ~20-second ACCESS DENIED failures while copying cua_node\...\bin\corepack.
• Fresh launches repeatedly created incomplete .staging-dd584937042db7da-* runtime directories.

Mitigation

$pkg  = Get-AppxPackage OpenAI.Codex
$cVol = Get-AppxVolume -Path C:\
Move-AppxPackage -Package $pkg.PackageFullName -Volume $cVol

The operation ultimately completed successfully. OpenAI.Codex_26.818.4152.0 is now registered on the system C: AppxVolume with Status: Ok, and no Codex package remains registered on the D: AppxVolume.

After the move

• First launch: usable window in approximately 10–15 seconds.
• A fresh cua_node runtime directory was successfully created instead of another failed .staging-* directory.
• bin\corepack was successfully deployed with a non-zero size (334 bytes).
• Clean quit terminated the subprocesses immediately.
• Second clean launch: window appeared in approximately 5 seconds and was fully usable within about 15 seconds, with no observed meaningful lag or freeze.
• This test/reply was performed from the working Codex desktop app.

This is strong before/after evidence that, on this machine, installation on the non-system AppxVolume was triggering the protected-file/runtime-copy failure, and moving the package to the system AppxVolume resolved it.

OpenAI feedback/session ID for telemetry correlation:
no-active-thread-01a02688-33dd-75d0-b392-ee91c8b003c6

Current installed Codex package tested: 26.818.4152.0
Windows 11 build: 26200.9168