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

What version of the Codex App are you using?

ChatGPT/Codex Windows package 26.810.4967.0; bundled CLI codex-cli 0.148.0-alpha.9.

What platform is your computer?

• Microsoft Windows NT 10.0.26200.0 x64
• Microsoft Store / MSIX package OpenAI.Codex
• WSL 2.7.11.0, Ubuntu 22.04, kernel 6.18.33.2-microsoft-standard-WSL2

What issue are you seeing?

After enabling the WSL agent and restarting, the app can fail with:

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

The Linux binary is present at app\resources\codex. The failure occurs while the app relocates the bundled Linux executables from the protected WindowsApps package into %USERPROFILE%\.codex\bin\wsl\<hash>.

The source is marked Archive, Encrypted. Reproducing the copy directly gives:

$src = (Get-AppxPackage OpenAI.Codex).InstallLocation + '\app\resources\codex'
Copy-Item -LiteralPath $src -Destination "$env:TEMP\codex-copytest" -Force

The specified file could not be encrypted.
HRESULT: 0x80071770 (ERROR_ENCRYPTION_FAILED / Win32 error 6000)

The destination staging root is created but remains empty after the failed relocation. Windows-native mode works because it uses resources\codex.exe in place and does not perform this copy.

What steps can reproduce the bug?

1. Install the Microsoft Store build whose app\resources\codex has the Encrypted attribute.
2. Select WSL as the agent environment and restart the app.
3. Observe the missing-CLI startup error.
4. Check %USERPROFILE%\.codex\bin\wsl; the expected staging directory is absent or empty.
5. Run the PowerShell copy test above and observe 0x80071770.

Current workaround

Pre-stage decrypted copies of codex, codex-code-mode-host, and rg in the hash directory expected by the app:

1. Read each packaged file with File.OpenRead and write it with File.Create so the destination does not inherit EFS/Application Protected encryption.
2. Verify file size and SHA-256 against the packaged sources.
3. Place the files under %USERPROFILE%\.codex\bin\wsl\<descriptor-hash> and restart the app.

This works: the staged codex starts successfully inside WSL and reports codex-cli 0.148.0-alpha.9. However, every app update changes the bundled binary hashes and therefore the expected directory, so the workaround must be repeated.

What is the expected behavior?

The app should relocate Application Protected/EFS-encrypted package resources to an unencrypted user directory, for example by using a copy path equivalent to COPY_FILE_ALLOW_DECRYPTED_DESTINATION, and should surface the underlying Win32 error instead of reporting that the CLI is missing.

Additional information

This appears to be the WSL CLI variant of the same protected-file relocation problem reported in #25220 and #34764. Related WSL startup reports include #28086, #30094, and #36777, but those reports do not identify ERROR_ENCRYPTION_FAILED during the bundled Linux CLI copy.

No WindowsApps permissions, ownership, package files, or encryption settings were modified.

Start with the WSL agent startup path that relocates app\resources\codex, codex-code-mode-host, and rg into %USERPROFILE%.codex\bin\wsl<hash>. Reproduce the PowerShell Copy-Item failure and compare it with the documented File.OpenRead/File.Create workaround. Done means packaged encrypted files are staged successfully in the user directory and the underlying Win32 error is surfaced when relocation still fails.