[Windows][WSL] MSIX EFS-encrypted bundled codex fails relocation with ERROR_ENCRYPTION_FAILED (0x80071770)

I maintain WinBridge Recovery, an independent Windows recovery/diagnostic project for Codex Desktop local plugin/runtime state: https://github.com/zemeng5208/winbridge-recovery

This report is a very close match to the same Windows local-copy failure class WinBridge has been built around: protected MSIX/WindowsApps resources are readable/hashable, but normal relocation into a per-user staging directory fails because the source carries Application Protected / EFS semantics. The useful local layer to inspect here is specifically the packaged source attributes plus the generated %USERPROFILE%\.codex\bin\wsl\<hash> staging target (including partial/empty staging left after a failed copy), not account/rollout state.

WinBridge can help diagnose this class of local state drift and, where its current recovery path applies, rebuild user-writable copies from the already-installed official package with verification rather than modifying WindowsApps. It also verifies package/version/hash changes so stale staged content is not silently reused after an update.

A limitation worth making explicit: WinBridge's published primary scope is Browser / Chrome / Computer Use recovery, so I would not treat it as a guaranteed fix for this WSL CLI relocation path. If the Desktop build itself always retries the WSL copy with a method that cannot create a decrypted destination, the durable fix still belongs upstream (for example a COPY_FILE_ALLOW_DECRYPTED_DESTINATION-equivalent path and reuse of a verified existing staged copy). It also does not change WindowsApps ownership, ACLs, or encryption policy.

The 0x80071770 / ERROR_ENCRYPTION_FAILED reproduction in this issue is especially useful because it distinguishes a package-protection copy failure from a genuinely missing resources\codex binary.

On Windows x64 26.820.7780.0, this Application Protected / ERROR_ENCRYPTION_FAILED relocation problem is no longer limited to the WSL CLI. The new build first requires relocation of the Windows-native codex.exe; when that fails, the entire desktop app exits during bootstrap.

I added a complete, successfully recovered case at https://github.com/openai/codex/issues/40700#issuecomment-5419391502. It materializes verified per-user copies of all startup-time relocation resources from the currently installed official package: Windows CLI, cua_node, Windows rg, WSL CLI, and WSL rg. Afterward, the app started successfully and both the local and WSL app servers reached initialized=true / connected.

This confirms that the WSL workaround documented here is directionally correct, but 26.820 must cover all startup-time relocation resources; restoring only %USERPROFILE%\.codex\bin\wsl is no longer sufficient. The linked comment includes the current directory IDs, recovery script, safety boundaries, and before/after validation.

Because the complete procedure is relatively involved, the simplest option when the ChatGPT desktop app cannot start is to give that comment permalink to a working Codex CLI on Windows or WSL, or to a ChatGPT desktop session running inside WSL. The agent should verify the installed version and logs first, and only then perform and validate the recovery.

I can reproduce the same issue on a newer Codex Windows build, 26.820.7780.0, so this appears to still be unresolved in 26.820.

Environment:

• Windows x64
• Microsoft Store / MSIX package: "OpenAI.Codex"
• Package version: "26.820.7780.0"
• Install location: "C:\Program Files\WindowsApps\OpenAI.Codex_26.820.7780.0_x64__2p2nqsd0c76g0"

Observed behavior:

1. Codex fails to start with:

"Unable to locate the Codex CLI binary. Set CODEX_CLI_PATH or ensure the Electron resources include bin/codex."

1. Both bundled binaries are present:

• "app\resources\codex" → "True"
• "app\resources\codex.exe" → "True"

1. The bundled Linux "codex" has:

"Attributes: Archive, Encrypted"

1. Attempting to copy it using PowerShell:

"Copy-Item -LiteralPath "$pkg\app\resources\codex" -Destination "$env:TEMP\codex-copytest" -Force"

fails with:
"Copy-Item : The specified file could not be encrypted."
("无法加密指定的文件" on my localized Windows installation)

1. "%USERPROFILE%\.codex\bin\wsl" does not contain the expected descriptor-hash staging directory after the failure.

1. Check for Updates reports the app is up to date, and Windows App Repair does not resolve the problem.

I also confirmed that reading the encrypted packaged "codex" with "System.IO.File.ReadAllBytes()" and writing it to a normal user directory produces an unencrypted copy ("Attributes: Archive"), further suggesting that the failure is specifically related to relocation/copying of the Application Protected/EFS-encrypted MSIX resource.

This appears to reproduce the same "ERROR_ENCRYPTION_FAILED" relocation issue reported here, but importantly it is still present in 26.820.7780.0.

One additional 26.820.7780.0 data point that may help narrow down the fatal bootstrap dependency:

The Windows-native bundled CLI reproduces the same copy failure

The comments above already confirm the protected-resource failure for the bundled WSL/Linux app\resources\codex.

I independently tested the Windows-native binary as well:

$pkg = Get-AppxPackage OpenAI.Codex
$winCli = Join-Path $pkg.InstallLocation 'app\resources\codex.exe'

Get-Item $winCli |
    Select-Object FullName, Length, Attributes

On my 26.820.7780.0 installation, codex.exe is also reported as Encrypted:

C:\Program Files\WindowsApps\OpenAI.Codex_26.820.7780.0_x64__2p2nqsd0c76g0\app\resources\codex.exe

Length:     307568432
Attributes: ..., Encrypted

Copying the native executable to a normal user-writable location fails the same way:

Copy-Item `
    -LiteralPath $winCli `
    -Destination "$env:TEMP\codex-win-copytest.exe" `
    -Force

Result on zh-CN Windows:

Copy-Item : 无法加密指定的文件。
FullyQualifiedErrorId :
System.IO.IOException,Microsoft.PowerShell.Commands.CopyItemCommand

So I can independently reproduce the protected/encrypted copy failure for both:

app\resources\codex
app\resources\codex.exe

Disabling WSL alone was not sufficient

I explicitly switched Desktop to Windows-native mode:

[desktop]
runCodexInWindowsSubsystemForLinux = false
integratedTerminalShell = "powershell"

but Desktop still exited during bootstrap with:

Unable to locate the Codex CLI binary.
Set CODEX_CLI_PATH or ensure the Electron resources include bin/codex.

This is consistent with the newer 26.820 behavior described above: the fatal startup path is no longer limited to provisioning the WSL CLI.

Minimal startup bypass: external native CLI via CODEX_CLI_PATH

I then installed the official Windows CLI separately through npm:

npm install -g @openai/codex
codex --version

Result:

codex-cli 0.149.1

The actual native executable is outside WindowsApps:

D:\nodejs\node_modules\@openai\codex\node_modules\@openai\codex-win32-x64\vendor\x86_64-pc-windows-msvc\bin\codex.exe

It executes normally.

I pointed CODEX_CLI_PATH directly at that native executable:

[Environment]::SetEnvironmentVariable(
    "CODEX_CLI_PATH",
    $nativeCli,
    "User"
)

After restarting the Windows session, Codex Desktop was able to start again.

The potentially useful distinction here is that I did not reconstruct the complete per-user staging tree or recover all packaged runtime resources first. Providing a healthy Windows-native codex.exe outside the protected MSIX package was sufficient to get Desktop past the fatal bootstrap failure on this machine.

I have not verified that this restores every other relocated runtime/helper (WSL helpers, Browser / Computer Use resources, etc.), so I would treat this specifically as a minimal Desktop-startup workaround, not as a complete recovery.

This may help identify which failed relocation is actually fatal during the early 26.820 bootstrap path.

A verified workaround without rolling back, modifying WindowsApps ACLs/ownership, or setting CODEX_CLI_PATH.
And stated the root cause
https://github.com/openai/codex/issues/40700#issuecomment-5419391502

I can reproduce the same issue on a newer Codex Windows build, 26.820.7780.0, so this appears to still be unresolved in 26.820. Environment: Windows x64 Microsoft Store / MSIX package: "OpenAI.Codex" Package version: "26.820.7780.0" Install location: "C:\Program Files\WindowsApps\OpenAI.Codex_26.820.7780.0_x64__2p2nqsd0c76g0" Observed behavior: 1. Codex fails to start with: "Unable to locate the Codex CLI binary. Set CODEX_CLI_PATH or ensure the Electron resources include bin/codex." 2. Both bundled binaries are present: "app\resources\codex" → "True" "app\resources\codex.exe" → "True" 3. The bundled Linux "codex" has: "Attributes: Archive, Encrypted" 4. Attempting to copy it using PowerShell: "Copy-Item -LiteralPath "$pkg\app\resources\codex" -Destination "$env:TEMP\codex-copytest" -Force" fails with: "Copy-Item : The specified file could not be encrypted." ("无法加密指定的文件" on my localized Windows installation) 5. "%USERPROFILE%.codex\bin\wsl" does not contain the expected descriptor-hash staging directory after the failure. 6. Check for Updates reports the app is up to date, and Windows App Repair does not resolve the problem. I also confirmed that reading the encrypted packaged "codex" with "System.IO.File.ReadAllBytes()" and writing it to a normal user directory produces an unencrypted copy ("Attributes: Archive"), further suggesting that the failure is specifically related to relocation/copying of the Application Protected/EFS-encrypted MSIX resource. This appears to reproduce the same "ERROR_ENCRYPTION_FAILED" relocation issue reported here, but importantly it is still present in 26.820.7780.0.

Codex Desktop on Windows + WSL is currently broken for me after restart/update.

Environment:

• Codex Desktop: 26.820.7780.0
• WSL2 Ubuntu: working normally
• Linux codex-cli 0.146.0: working normally

Desktop fails at startup with:
Unable to locate the Codex CLI binary

Logs repeatedly show:
bundled_executable_relocation_failed
during copy_file / copy_directory, with UNKNOWN (-4094) errors.

cipher /c confirms the bundled codex.exe under WindowsApps is Application Protected.

So this is not a broken WSL installation or Linux CLI. The Desktop bootstrap/runtime relocation path itself is failing.

Please fix the Windows + WSL cold-start/update path and add a regression test for this exact scenario. Users should not have to debug MSIX packaging internals just to restart an IDE.

And seriously: either make Windows + WSL stable, or give us a proper Linux desktop build. Right now both paths feel unnecessarily fragile.

[Windows][MSIX][26.820.60940] Bundled Codex executable relocation fails from WindowsApps on a secondary Appx volume, causing false “Unable to locate Codex CLI” startup error

This comment extends the issue from WSL relocation to the Windows-native bundled executable path in app version 26.820.60940.

Summary

The Codex Windows desktop app failed at startup with:

ChatGPT failed to start. Unable to locate the Codex CLI binary. Set CODEX_CLI_PATH or ensure the Electron resources include bin/codex.

The bundled codex.exe was not missing. It existed under the installed MSIX resources, had a valid OpenAI Authenticode signature, and was readable for inspection.

The first recorded failure was instead a bundled-executable relocation error. The app attempted to copy the packaged executable from WindowsApps into %LOCALAPPDATA%\OpenAI\Codex\bin\.staging-*; Node/Electron reported:

• syscall=copyfile
• errno=-4094
• code=UNKNOWN
• sourceKind=windowsapps

The locator then returned no executable and converted this copy failure into the fatal “Unable to locate” message.

The package was installed on a secondary NTFS Appx volume, F:, with the nominal C: WindowsApps path implemented as a junction to F:. The packaged executable had the Encrypted attribute.

Installing the native Codex CLI, setting CODEX_CLI_PATH directly to its codex.exe, and rebooting allowed the desktop app to start. This workaround bypasses the failed bundled relocation; it does not repair it.

Environment

• OS: Windows 11 Pro x64, 10.0.26200
• PowerShell: 7.6.4
• Codex desktop product version from Electron metadata: 26.820.60940
• MSIX package: OpenAI.Codex_26.820.7780.0_x64
• MSIX entry executable: app\ChatGPT.exe
• Native Codex CLI after workaround: codex-cli 0.149.1
• Registered package path:

C:\Program Files\WindowsApps\OpenAI.Codex_26.820.7780.0_x64__...\

• Physical junction target:

F:\WindowsApps\OpenAI.Codex_26.820.7780.0_x64__...\

• C: and F: are healthy NTFS volumes; F: is the registered non-system Appx volume.
• A separately installed legacy package, OpenAI.ChatGPT-Desktop 1.2026.190.0, was not the package producing this error. The OpenAI.Codex package uses ChatGPT.exe as its entry point, which likely explains the “ChatGPT failed to start” wording.

Current post-workaround CLI state:

codex --version
codex-cli 0.149.1

where.exe codex
C:\Users\<USERNAME>\AppData\Local\Programs\OpenAI\Codex\bin\codex.exe

Get-Command codex -All and Get-Command codex.exe -All now resolve only to that native executable. No npm codex, codex.cmd, codex.ps1, or npm-managed @openai/codex package remains.

The user- and process-level CODEX_CLI_PATH now point to the native executable; the machine-level variable is unset.

Observed behavior

1. The desktop app failed immediately during bootstrap.
2. Reinstalling the Store/MSIX application did not fix the problem. Appx deployment events show the repaired/reinstalled package was again staged and registered on F:.
3. The application found the bundled resource but failed while copying it into a per-user stable directory.
4. The copy failure was reduced to UNKNOWN/-4094.
5. The locator returned null, after which the application displayed the misleading missing-CLI dialog and terminated.
6. Five failed startup sessions were recorded before the workaround.
7. Across pre- and post-workaround logs, 16 codex.exe relocation failures were recorded. The first successful session still logged bundled relocation errors, then spawned the explicitly configured native executable.
8. Similar UNKNOWN copy failures were recorded for bundled node, node_repl, corepack, and rg.exe, so the underlying relocation defect is broader than CLI discovery.

Expected behavior

• A package-installed application should reliably use or relocate its bundled executable, including when the MSIX is stored on a secondary Appx volume.
• Encrypted/Application-Protected package files should be copied to an unencrypted user destination using an appropriate Windows copy mechanism.
• If relocation fails, the error should identify the copy stage and underlying Windows error, rather than claiming the binary is missing.
• Failure to initialize the CLI should not necessarily prevent the desktop UI from opening.
• If an external CLI is supported, the app should validate that it resolves to a native Windows executable and fall back gracefully.
• The diagnostic message should enumerate the actual attempted paths. The current message mentions bin/codex, while the installed Windows implementation checks locations such as resources\codex.exe.

Steps to reproduce

Status: evidence-backed reproduction candidate, not intentionally re-run after the workaround because doing so would require breaking a currently working installation.

1. Configure a secondary NTFS Windows Appx volume.
2. Install or move the Microsoft Store OpenAI.Codex package to that volume.
3. Confirm that app\resources\codex.exe has the Encrypted attribute.
4. Start the app in native Windows mode without a valid external CODEX_CLI_PATH.
5. Observe a bundled_executable_relocation_failed event while copying from WindowsApps to:

C:\Users\<USERNAME>\AppData\Local\OpenAI\Codex\bin\.staging-*\codex.exe

1. Observe the fatal “Unable to locate the Codex CLI binary” message.
2. As a control, install the native Codex CLI and set:

CODEX_CLI_PATH=C:\Users\<USERNAME>\AppData\Local\Programs\OpenAI\Codex\bin\codex.exe

1. Start a new Windows session or reboot.
2. Confirm that the desktop app starts and spawns the external native executable.

An npm-managed Codex shim existed earlier in the original user timeline, but current evidence does not show that npm coexistence is required to reproduce the initial bundled-relocation failure. It should be tested separately.

Diagnostic evidence

Bundled executable verification:

Resource: app\resources\codex.exe
Size: 307,568,432 bytes
Attributes: Archive, Encrypted
Authenticode status: Valid
Signer: OpenAI OpCo LLC
SHA-256: 09D6723925E724EDF0BBBBC7B9E204526E0FB1462C86BD2A4997311FD5071EBA

Condensed and redacted failure:

2026-08-26T06:59:39Z  bundled_executable_relocation_failed

executableName=codex.exe
sourceKind=windowsapps
operation=copy_file
errorCode=UNKNOWN
originalError.errno=-4094
originalError.code=UNKNOWN
originalError.syscall=copyfile

sourcePath=
C:\Program Files\WindowsApps\
OpenAI.Codex_26.820.7780.0_x64__...\
app\resources\codex.exe

destinationPath=
C:\Users\<USERNAME>\AppData\Local\OpenAI\Codex\bin\
.staging-...\codex.exe

The next events report failure to connect to the app server, followed by:

Unable to locate the Codex CLI binary.
Set CODEX_CLI_PATH or ensure the Electron resources include bin/codex.

Condensed successful session after the workaround:

2026-08-26T07:30:37Z
executablePath=
C:\Users\<USERNAME>\AppData\Local\Programs\OpenAI\Codex\bin\codex.exe

2026-08-26T07:30:38Z
Codex CLI initialized
currentVersion=0.149.1

Additional findings:

• The destination directory grants the user full control, and staging directories can be created.
• No relevant Defender threat-detection event or conventional application-crash event was found in the failure window.
• No completed bundled relocation directory exists under %LOCALAPPDATA%\OpenAI\Codex\bin.
• Static inspection of the installed, minified app.asar indicates that the native Windows relocation route uses fs.copyFileSync and returns null after a copy exception.
• The same installed ASAR contains a separate Windows copy helper capable of using CopyFileExW with COPY_FILE_ALLOW_DECRYPTED_DESTINATION, but the native bundled-executable relocation path does not appear to use that helper.
• OpenAI’s public source listing and public Codex repository expose the CLI, SDK and App Server, but not the desktop bootstrap/locator source, so the installed ASAR had to be inspected locally; these desktop implementation findings cannot be cross-checked against public source. OpenAI open-source listing, openai/codex

The official Codex installer had previously detected the npm-managed installation and warned:

Multiple managed Codex installs can be ambiguous because PATH order decides which one runs.

That warning is relevant to wrapper coexistence, but it does not explain the earlier copyfile failure by itself.

Workaround that fixed the issue

1. Remove the npm-managed @openai/codex package.
2. Install native Codex CLI 0.149.1.
3. Verify that codex, where.exe codex, and Get-Command codex.exe -All resolve to the native executable.
4. Set the user-level environment variable:

CODEX_CLI_PATH=C:\Users\<USERNAME>\AppData\Local\Programs\OpenAI\Codex\bin\codex.exe

1. Reboot Windows.

After reboot, the desktop application started successfully and initialized Codex CLI 0.149.1.

This is a confirmed bypass. Because bundled codex.exe, Node runtime, and rg.exe relocation failures remain in the logs, it should not be treated as a full fix.

Probable root cause

Confirmed application-level cause:

The bundled executable exists, but its relocation fails during copyFileSync. The locator converts the copy failure into a null result, and desktop bootstrap treats that result as a missing CLI.

Probable Windows-level trigger:

The source is an encrypted MSIX resource on a secondary Appx volume. A normal Windows copy operation attempts to preserve encryption and can fail when the destination cannot be encrypted with an available key.

Microsoft documents that COPY_FILE_ALLOW_DECRYPTED_DESTINATION permits an encrypted source file to be copied even when the destination cannot be encrypted. Microsoft CopyFileEx documentation, handling encrypted files.

This is also consistent with:

• Existing OpenAI issue #38696, which records ERROR_ENCRYPTION_FAILED / Win32 6000 while relocating encrypted MSIX resources in WSL mode.
• Node’s vendored libuv Windows copy path using CopyFileW without the decrypted-destination flag, followed by mapping unrecognized Windows errors to UV_UNKNOWN; UV_UNKNOWN is -4094. libuv copy implementation, Windows error mapping, UV_UNKNOWN.

The precise Electron/libuv build and underlying Win32 error were not captured in this machine’s application log. Therefore ERROR_ENCRYPTION_FAILED is a strong inference, not yet a confirmed local Win32 result.

It is also not yet proven whether the secondary volume alone is sufficient, or whether the necessary combination is secondary volume + C: junction + encrypted package resource.

Alternative hypotheses

| Hypothesis | Assessment |
| --- | --- |
| npm shim/PATH conflict | Not the primary cause of the logged initial failure. The failure occurs during bundled-file copying before any CLI process is spawned. |
| Incorrect executable-resolution logic | Partially supported. The fallback/error logic is defective, and the message names an outdated or inaccurate bin/codex location. Ambient PATH does not appear to be the default recovery path in the inspected build. |
| Bundled Codex missing | Refuted. resources\codex.exe exists, is readable, hashes successfully, and has a valid OpenAI signature. |
| Incorrect bundled resource path | The app reached the correct packaged file; the failure was copying it, not finding it. |
| Environment inheritance | Reboot/new process was needed for the new user variable to be observed, which is normal Windows behavior. It does not explain the original bundled copy failure. |
| Stale CLI discovery/cache | No supporting evidence. No completed relocation cache exists, and reinstalling on the same Appx volume reproduced the failure. |
| .cmd/.ps1 spawn incompatibility | Plausible as a separate secondary defect. Existing issue #40752 reports spawn EINVAL when CODEX_CLI_PATH targets a .cmd wrapper. It does not explain the default relocation failure. Node also documents special Windows handling requirements for .bat and .cmd files. Node child-process documentation |
| ACL or antivirus block | Lower probability. The source could be inspected, the destination was writable, Appx ACL repair succeeded, and no Defender threat event matched the failure window. A filesystem filter-driver contribution cannot be completely excluded. |

Suggested engineering fix

1. Use a Windows copy implementation that supports COPY_FILE_ALLOW_DECRYPTED_DESTINATION for bundled Appx resources.
2. Reuse the existing robust Windows copy helper consistently for native CLI, WSL CLI, Node runtime and rg.exe relocation.
3. Alternatively, open the source for reading, create a new unencrypted destination file, then verify length, SHA-256 and expected signature before activation.
4. Preserve and log the original Win32 error or HRESULT, rather than exposing only libuv UNKNOWN/-4094.
5. Log the full ordered list of attempted locations and clearly distinguish:

• resource missing;
• resource copy failed;
• validation failed;
• executable spawn failed.

1. Replace the misleading bin/codex wording with the actual attempted Windows paths.
2. Allow the desktop UI to open in a degraded/repair state when CLI initialization fails.
3. Support a native external executable as a fallback.
4. If CODEX_CLI_PATH points to .cmd or .ps1, either resolve the underlying native codex.exe or reject the wrapper with an actionable error. Do not enable an unrestricted shell merely to make arbitrary wrappers executable.

Regression-test recommendations

Test the following matrix:

• System Appx volume vs secondary Appx volume.
• Direct WindowsApps path vs system-volume junction to a secondary volume.
• Encrypted vs unencrypted packaged resources.
• Native Windows mode vs WSL mode.
• x64 vs ARM64.
• Fresh install, update, repair/reinstall and moved package.
• No CODEX_CLI_PATH.
• CODEX_CLI_PATH pointing to a valid native .exe.
• Variable pointing to .cmd, .ps1, missing file and non-executable file.
• npm CLI only, native CLI only and both installed.
• Relocation success, ERROR_ENCRYPTION_FAILED, access denied, disk full and hash mismatch.

Assertions should verify that:

• encrypted-resource relocation succeeds;
• the copied binary’s size/hash/signature match;
• raw Win32 errors survive into diagnostic logs;
• a relocation failure does not become a misleading “binary missing” error;
• UI startup remains available for repair;
• no stale staging directory is selected after an interrupted copy.

Privacy/redaction notes

• The Windows username has been replaced with <USERNAME>.
• Email addresses, account information, authentication material, cookies, tokens, session IDs, turn IDs and unrelated files are excluded.
• Do not upload entire raw log files: they contain unrelated identifiers.
• The package version, package family name, executable hash, drive letters, generic timestamps and redacted error paths are suitable for the engineering report.