[Windows 26.820] Codex Desktop cannot start: bundled codex.exe relocation from WindowsApps fails

[bevis7781]

What version of the Codex App are you using (From “About Codex” dialog)?

26.820.7780.0 (from Get-AppxPackage; the app cannot start to open the About Codex dialog)

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

After updating Codex Desktop to version 26.820.7780.0, the app can no longer start.

The startup dialog reports:

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

However, the bundled Windows CLI is present at:

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

The startup logs show that the actual failure occurs earlier, while Codex attempts to relocate the bundled Windows executable from the WindowsApps package into the per-user runtime directory.

Relevant log fields:

bundled_executable_relocation_failed
operation=copy_file
executableName=codex.exe
failedExecutableName=codex.exe
sourceKind=windowsapps

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

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

originalError:
errno=-4094
code=UNKNOWN
syscall=copyfile

Immediately afterwards, AppServerConnection fails with:

Unable to locate the Codex CLI binary.

The bundled files:

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

both report the Windows file attributes:

Archive, Encrypted

A manual copy test of the bundled codex file from WindowsApps to a normal temporary directory also fails with:

The specified file could not be encrypted.

During the same startup sequence, Codex also fails to relocate the bundled cua_node runtime using copy_directory.

The app worked before the update and stopped starting immediately after updating to 26.820.7780.0.

What steps can reproduce the bug?

1. Update/install Codex Desktop from the Microsoft Store to version 26.820.7780.0 on this Windows x64 machine.

2. Launch Codex Desktop.

3. The app attempts to relocate the bundled codex.exe from the WindowsApps package into:
   %LOCALAPPDATA%\OpenAI\Codex\bin\

4. The relocation fails during copy_file.

5. Codex then displays:
   "Unable to locate the Codex CLI binary."

Potentially relevant AppX environment details:

Get-AppxDefaultVolume reports:

D:\WindowsApps

Get-AppxPackage OpenAI.Codex reports:

Version:
26.820.7780.0

InstallLocation:
C:\Program Files\WindowsApps\OpenAI.Codex_26.820.7780.0_x64__2p2nqsd0c76g0

A directory for the same Codex package/version is visible under both:

C:\Program Files\WindowsApps
D:\WindowsApps\

I have not modified WindowsApps permissions, ownership, ACLs, package files, encryption settings, Codex configuration, or CODEX_CLI_PATH.

What is the expected behavior?

Codex Desktop should successfully locate or relocate the bundled Windows Codex CLI and start normally.

If WindowsApps / Application Protected / encrypted package resources cannot be copied to the per-user runtime directory using the current copy mechanism, Codex should use a Windows-compatible relocation method and surface the underlying Windows error instead of reporting that the CLI is missing.

Additional information

This appears related to existing Windows bundled-runtime relocation issues, but the impact in this case is more severe: the Windows-native codex.exe relocation failure prevents the entire Codex Desktop app from starting.

Potentially related issues:

#25571 - WindowsApps package on a non-system AppX volume / protected bundled executable relocation failures
#38696 - encrypted bundled Codex relocation failure in the WSL path
#34764 - Application Protected cua_node relocation failure

The same startup sequence on this machine shows both codex.exe copy_file relocation failures and cua_node copy_directory relocation failures.

The "Check for Updates" button in the startup error dialog still works and currently reports:

ChatGPT is up to date.

No workaround or local modification has been applied after reproducing the issue, so the failing installation state is currently preserved.

[ahku667]

I can independently reproduce this on the exact same Windows package:

• OpenAI.Codex 26.820.7780.0 x64
• Windows 11 10.0.26200.0
• ChatGPT Plus

Important: my Desktop configuration is Windows-native:

runCodexInWindowsSubsystemForLinux = false
integratedTerminalShell = "powershell"

The bundled binaries are present:

app\resources\codex.exe = exists
app\resources\codex     = exists

Both report:

Attributes: Archive, Encrypted

A direct copy reproduction of the packaged Linux codex binary to %TEMP% fails with:

COPY_RESULT=FAILED
ERROR=The specified file could not be encrypted.
HRESULT=80071770

The Desktop startup log shows the same Windows-native relocation failure:

bundled_executable_relocation_failed
operation=copy_file
executableName=codex.exe
failedExecutableName=codex.exe
sourceKind=windowsapps

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

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

Immediately afterwards:

Unable to locate the Codex CLI binary.

The same startup sequence also contains relocation failures for the bundled cua_node / Node runtime using copy_directory.

Windows Settings > Apps > ChatGPT > Repair did not resolve the issue.

I did not modify WindowsApps ownership, ACLs, package files, encryption, CODEX_CLI_PATH, the bundled binaries, or Codex runtime state before reproducing this.

Additional AppX-volume evidence from a final read-only audit:

REGISTERED_INSTALL_LOCATION=
C:\Program Files\WindowsApps\OpenAI.Codex_26.820.7780.0_x64__2p2nqsd0c76g0

DEFAULT_APPX_VOLUME=
F:\WindowsApps

An exact package directory for the same package full name also exists at:

F:\WindowsApps\OpenAI.Codex_26.820.7780.0_x64__2p2nqsd0c76g0

The C: and F: copies of both bundled binaries are byte-identical by size and SHA-256:

codex.exe
size = 307,568,432 bytes
sha256 = 09D6723925E724EDF0BBBBC7B9E204526E0FB1462C86BD2A4997311FD5071EBA
attributes = Archive, Encrypted

codex
size = 265,274,528 bytes
sha256 = EC77CF443344309A29859E16204CAC6F0BAE162FFD39427E94F24AEEBB5E3D68
attributes = Archive, Encrypted

The hashes are identical on C: and F:.

So this machine has a multi-AppX-volume mismatch/state in which the default AppX volume is F:, the registered Codex package install location is C:, and an identical copy of the same package/version is also present under F:\WindowsApps.

I cannot prove that this multi-volume state is the root cause rather than only a trigger/amplifier, but it closely matches the potentially relevant environment shape already described in #40700.

This appears to confirm that #40700 affects the Windows-native path itself, not only the WSL agent path, and that the underlying failure is consistent with ERROR_ENCRYPTION_FAILED (0x80071770) / protected MSIX resource relocation.

[hz3204323]

I can reproduce this exact regression on Windows x64.

Working: 26.818.8289.0
Broken: 26.820.7780.0

Additional evidence from my machine:

• app\resources\codex.exe and app\resources\codex both exist in the 26.820.7780.0 package.
• Both report Windows file attributes Archive, Encrypted / Application Protected behavior.
• The earliest native startup failure is:
  • bundled_executable_relocation_failed
  • executableName=codex.exe
  • platform=win32
  • operation=copy_file
  • source: ...\WindowsApps\OpenAI.Codex_26.820.7780.0...\app\resources\codex.exe
  • destination: %LOCALAPPDATA%\OpenAI\Codex\bin\.staging-...\codex.exe
  • errno=-4094, code=UNKNOWN
• Only after that does the UI report Unable to locate the Codex CLI binary.
• A manual Copy-Item of the bundled codex file from WindowsApps to %TEMP% fails with: The specified file could not be encrypted.

This is the Windows-native CLI path in my failing log, not the WSL bootstrap path. CODEX_CLI_PATH is unset, and the runCodexInWindowsSubsystemForLinux setting is not present in my config.

My %USERPROFILE%\.codex is a Junction to D:\ChatGPT\CodexHome, but that same Junction/D-drive layout was present while 26.818.8289.0 worked normally, so it does not explain the version-specific regression.

I also compared the two desktop builds: 26.818.8289.0 can directly resolve/run the bundled resources\codex.exe, while 26.820.7780.0 routes startup through the relocation helper first. The old build also logged some bundled-runtime/plugin copy warnings, but they were non-fatal; the new build appears to make successful native codex.exe relocation a prerequisite for startup.

I downloaded the official previous release MSIX from OpenAI's CDN and downgraded with:

Add-AppxPackage "$HOME\Downloads\ChatGPT-x64.msix" -ForceUpdateFromAnyVersion

After returning to 26.818.8289.0, the desktop app started immediately and my existing projects, sessions, and configuration were still intact.

This looks like a regression in the new mandatory Windows-native CLI relocation path when the source resource is Store/MSIX Application Protected.

[xianlitijun]

Independent reproduction of this release regression on Windows 11:

• ChatGPT/Codex Desktop was working normally before today's (2026-08-25) Windows app update.

• Immediately after updating to the latest release, the app fails on first launch with the same fatal dialog:

  ChatGPT failed to start.

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

• This machine had not encountered the issue on prior builds; the failure began only after today's update.

• The main app is now completely inaccessible, so this is a blocking startup regression rather than a feature-level failure.

• The startup dialog still exposes Check for Updates, but the current release is already the latest.

This appears consistent with #40700 and adds another update-triggered reproduction. A screenshot of the exact dialog is available if maintainers need it.

[zemeng5208]

I maintain WinBridge Recovery: https://github.com/zemeng5208/winbridge-recovery

This report is a high-confidence match for one of the local Windows layers WinBridge is designed to diagnose: bundled executable/runtime relocation from the installed MSIX/WindowsApps package into the per-user Codex runtime, including Application Protected/EFS copy failures and incomplete staging.

For this specific failure, the useful local checks are:

• verify that the packaged app\resources\codex.exe / codex and cua_node sources exist and are readable;
• inspect their Windows encryption/Application Protected state;
• inspect %LOCALAPPDATA%\OpenAI\Codex\bin and runtimes\cua_node for abandoned .staging-* directories or an incomplete active runtime;
• compare any existing per-user runtime files against the currently installed package by size/hash before deciding whether local state is reusable;
• distinguish a destination-path/Junction problem from the ERROR_ENCRYPTION_FAILED copy path shown here.

WinBridge can help collect that evidence and recover user-side staging/runtime state where a valid current-package copy can be materialized safely. It does not modify WindowsApps, bypass package protection, or guarantee a fix. In particular, if Desktop 26.820.7780.0 now requires codex.exe to be copied with a mechanism that does not allow an Application Protected source to an unencrypted destination, then the durable fix is upstream in Codex's Windows relocation implementation (for example, using a decrypted-destination-compatible copy path and reusing a verified existing runtime when appropriate).

[CanLoop16]

Same issue!!!

Run the following command in Windows Powershell and i get the correct respond:

> Get-AppxPackage *Codex* | Select-Object Name, PackageFullName, Version, InstallLocation

Name         PackageFullName                               Version       InstallLocation
OpenAI.Codex OpenAI.Codex_26.820.7780.0_x64__2p2nqsd0c76g0 26.820.7780.0 C:\Program Files\WindowsApps\OpenAI.Codex_2...

But run where.exe codex i can't find anything.

[eksynn]

I can reproduce this exactly on Windows x64 with OpenAI.Codex 26.820.7780.0.

The app worked normally before the update. Immediately after updating to 26.820.7780.0, startup failed with:

Unable to locate the Codex CLI binary.

My AppX configuration is:

Get-AppxDefaultVolume
PackageStorePath: B:\WindowsApps
IsSystemVolume: False

while the affected package was registered at:

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

I rolled back to the official 26.818.8289.0 MSIX using:

Add-AppxPackage -Path "B:\ChatGPT-Rollback\ChatGPT-26.818.8289.0-x64.msix" -ForceUpdateFromAnyVersion -ForceApplicationShutdown

and ChatGPT immediately launches normally again.

Please also make the updater preserve the user's configured/existing AppX installation volume. My Windows default app volume is explicitly B:\WindowsApps; the ChatGPT package should not silently fall back to or migrate onto C: during installation or updates.

If relocation of bundled runtime files is necessary, it should work correctly with a non-system AppX volume rather than requiring the application itself to live on C:.

[pwnfan]

I reproduced the same 26.820.7780.0 startup regression on another Windows x64 machine and recovered the app without rolling back, changing WindowsApps permissions or ownership, or setting CODEX_CLI_PATH.

✅ Start here: verified no-rollback recovery

This is not only a bug report. A working recovery is included in this comment and was validated on OpenAI.Codex 26.820.7780.0 x64. It restored normal desktop startup and both the Windows-native and WSL app servers without rolling back, modifying WindowsApps ACLs/ownership, or setting CODEX_CLI_PATH.

Comment permalink (copy this URL):

https://github.com/openai/codex/issues/40700#issuecomment-5419391502

Fastest option when the desktop app cannot start: give the permalink above to a Codex agent that still runs and can access the Windows host filesystem, for example:

• Codex CLI on Windows, even when the ChatGPT desktop app cannot start;
• Codex CLI inside WSL;
• a ChatGPT desktop session running inside WSL, or another Codex session that can access the Windows host paths.

You can send the agent this prompt:

Read this GitHub comment. First perform read-only checks of my installed ChatGPT/Codex desktop version, WindowsApps resource attributes, and latest startup log. Confirm that this is the same ERROR_ENCRYPTION_FAILED / bundled_executable_relocation_failed failure. Only if it matches, use the currently installed official package to materialize and verify the per-user caches described in the comment, then relaunch and validate startup. Do not change WindowsApps ACLs, ownership, package files, or my Codex configuration, and do not set CODEX_CLI_PATH.

The agent can adapt the paths to the actual installation and let the user review the commands before execution. Do not put account credentials, tokens, or other secrets in the GitHub comment or prompt.

If you prefer to perform the recovery manually, go directly to Manual recovery (PowerShell) below. The script dynamically computes the five version-directory IDs from the currently installed package. It has been validated on 26.820.7780.0 x64 and stops before writing if the known bundle layout is not present.

Root cause confirmation

The first failure is not the WSL environment failing to find a user-installed Codex CLI. The desktop app cannot copy resources carrying the Encrypted / Application Protected attribute from the MSIX package into its per-user cache:

bundled_executable_relocation_failed
operation=copy_file
executableName=codex.exe
sourceKind=windowsapps
originalError: The specified file could not be encrypted.
HRESULT: 0x80071770 / ERROR_ENCRYPTION_FAILED

Only afterward does it emit the misleading secondary errors:

Unable to locate the Codex CLI binary.
Desktop bootstrap failed to start the main app.

The same launch also fails while copying the cua_node directory and rg.exe. Therefore, restoring only the WSL codex file, setting CODEX_CLI_PATH, or reinstalling the same MSIX package is insufficient for this Windows-native bootstrap regression.

Version-directory rule used by the app

The app does not use a fixed bin/codex path. It derives a 16-character directory name from a resource descriptor. In the app-defined file order, each entry contributes:

<UTF-8 file name> NUL <lowercase SHA-256 hex digest of that file> NUL

The app hashes the complete descriptor with SHA-256 and uses its first 16 characters.

For the official 26.820.7780.0 x64 package, the resulting IDs are:

Windows CLI   d0097be4feba73d0
cua_node      950613ca46815e82
Windows rg    b91d382ea836415f
WSL CLI       bf0dd1e87d338bce
WSL rg        1a4f6f66dd2f3710

The Windows CLI descriptor contains, in order:

codex.exe
codex-code-mode-host.exe
codex-windows-sandbox-setup.exe
codex-command-runner.exe

The cua_node descriptor contains:

manifest.json
bin/node.exe
bin/node_repl.exe

The WSL CLI descriptor contains:

codex
codex-code-mode-host

Manual recovery (PowerShell)

The PowerShell script below selects the currently installed official OpenAI.Codex x64 package and dynamically computes all five version-directory IDs from its resource bytes. The same script can therefore be rerun after a future update when the bundle file lists, ordering, hashing algorithm, and cache layout remain unchanged. If a known bundle file is absent, it stops before writing. It reads package resources with FileStream and creates ordinary destination files so the destination does not inherit the source's Application Protected/EFS state. It writes into a random staging directory, verifies file size and SHA-256, and then renames the staging directory atomically.

Safety boundaries:

• It does not modify any WindowsApps file, ACL, ownership, or encryption setting.
• It does not modify Codex configuration, sessions, or CODEX_CLI_PATH.
• It computes directory IDs from the current package and fails closed if the known bundle layout has changed.
• It does not overwrite an existing mismatched version directory; it stops on a conflict.
• It only materializes user-writable caches from the currently installed official package and does not redistribute OpenAI binaries.
• Fully quit ChatGPT/Codex first. Copying the 4,018 cua_node files may take several minutes.

PowerShell recovery script (dynamic bundle IDs; known x64 package layout)

Set-StrictMode -Version Latest
$ErrorActionPreference = "Stop"

if (Get-Process ChatGPT, Codex -ErrorAction SilentlyContinue) {
    throw "Please fully quit ChatGPT/Codex before running this script."
}

$pkg = Get-AppxPackage OpenAI.Codex |
    Sort-Object Version -Descending |
    Select-Object -First 1

if ($null -eq $pkg) {
    throw "OpenAI.Codex is not installed."
}
if ($pkg.PackageFullName -notmatch "_x64__") {
    throw "This script is only validated for the known x64 package layout: $($pkg.PackageFullName)."
}

$resources = Join-Path $pkg.InstallLocation "app\resources"
$localRoot = Join-Path $env:LOCALAPPDATA "OpenAI\Codex"
$wslRoot = Join-Path $env:USERPROFILE ".codex\bin\wsl"

function Get-Sha256Hex([string]$Path) {
    $stream = [IO.File]::Open(
        $Path,
        [IO.FileMode]::Open,
        [IO.FileAccess]::Read,
        [IO.FileShare]::Read
    )
    $sha = [Security.Cryptography.SHA256]::Create()
    try {
        return ([BitConverter]::ToString($sha.ComputeHash($stream))).Replace("-", "").ToLowerInvariant()
    }
    finally {
        $sha.Dispose()
        $stream.Dispose()
    }
}

function Get-BundleId([string]$SourceRoot, [string[]]$LogicalNames) {
    $descriptor = [Text.StringBuilder]::new()
    foreach ($logicalName in $LogicalNames) {
        $physicalName = $logicalName.Replace([char]'/', [IO.Path]::DirectorySeparatorChar)
        $sourcePath = Join-Path $SourceRoot $physicalName
        if (-not (Test-Path -LiteralPath $sourcePath -PathType Leaf)) {
            throw "Unsupported bundle layout; missing file: $sourcePath"
        }
        [void]$descriptor.Append($logicalName)
        [void]$descriptor.Append([char]0)
        [void]$descriptor.Append((Get-Sha256Hex $sourcePath))
        [void]$descriptor.Append([char]0)
    }

    $sha = [Security.Cryptography.SHA256]::Create()
    try {
        $bytes = [Text.Encoding]::UTF8.GetBytes($descriptor.ToString())
        return ([BitConverter]::ToString($sha.ComputeHash($bytes))).Replace("-", "").ToLowerInvariant().Substring(0, 16)
    }
    finally {
        $sha.Dispose()
    }
}

$ids = @{
    WindowsCli = Get-BundleId $resources @(
        "codex.exe",
        "codex-code-mode-host.exe",
        "codex-windows-sandbox-setup.exe",
        "codex-command-runner.exe"
    )
    CuaNode = Get-BundleId (Join-Path $resources "cua_node") @(
        "manifest.json",
        "bin/node.exe",
        "bin/node_repl.exe"
    )
    WindowsRg = Get-BundleId $resources @("rg.exe")
    WslCli = Get-BundleId $resources @("codex", "codex-code-mode-host")
    WslRg = Get-BundleId $resources @("rg")
}

function Assert-SameFile([string]$Source, [string]$Destination) {
    if (-not (Test-Path -LiteralPath $Destination -PathType Leaf)) {
        throw "Missing destination file: $Destination"
    }
    if ((Get-Item -LiteralPath $Source).Length -ne (Get-Item -LiteralPath $Destination).Length) {
        throw "File size mismatch: $Destination"
    }
    if ((Get-Sha256Hex $Source) -ne (Get-Sha256Hex $Destination)) {
        throw "SHA-256 mismatch: $Destination"
    }
}

function Copy-PlainFile([string]$Source, [string]$Destination) {
    [IO.Directory]::CreateDirectory((Split-Path -Parent $Destination)) | Out-Null
    $inputStream = [IO.File]::Open(
        $Source,
        [IO.FileMode]::Open,
        [IO.FileAccess]::Read,
        [IO.FileShare]::Read
    )
    $outputStream = [IO.File]::Open(
        $Destination,
        [IO.FileMode]::CreateNew,
        [IO.FileAccess]::Write,
        [IO.FileShare]::None
    )
    try {
        $inputStream.CopyTo($outputStream)
    }
    finally {
        $outputStream.Dispose()
        $inputStream.Dispose()
    }
}

function Publish-FileBundle(
    [string]$SourceRoot,
    [string]$DestinationRoot,
    [string]$Id,
    [string[]]$Files
) {
    [IO.Directory]::CreateDirectory($DestinationRoot) | Out-Null
    $final = Join-Path $DestinationRoot $Id

    if (Test-Path -LiteralPath $final) {
        foreach ($relative in $Files) {
            Assert-SameFile (Join-Path $SourceRoot $relative) (Join-Path $final $relative)
        }
        return $final
    }

    $stage = Join-Path $DestinationRoot (".repair-{0}-{1}" -f $Id, [guid]::NewGuid().ToString("N"))
    [IO.Directory]::CreateDirectory($stage) | Out-Null
    try {
        foreach ($relative in $Files) {
            Copy-PlainFile (Join-Path $SourceRoot $relative) (Join-Path $stage $relative)
        }
        foreach ($relative in $Files) {
            Assert-SameFile (Join-Path $SourceRoot $relative) (Join-Path $stage $relative)
        }
        Move-Item -LiteralPath $stage -Destination $final
    }
    catch {
        if (Test-Path -LiteralPath $stage) {
            Remove-Item -LiteralPath $stage -Recurse -Force
        }
        throw
    }
    return $final
}

function Publish-DirectoryBundle(
    [string]$SourceRoot,
    [string]$DestinationRoot,
    [string]$Id,
    [string[]]$DescriptorFiles
) {
    [IO.Directory]::CreateDirectory($DestinationRoot) | Out-Null
    $sourceRoot = $SourceRoot.TrimEnd("\")
    $final = Join-Path $DestinationRoot $Id

    if (Test-Path -LiteralPath $final) {
        foreach ($relative in $DescriptorFiles) {
            Assert-SameFile (Join-Path $sourceRoot $relative) (Join-Path $final $relative)
        }
        $sourceCount = @(Get-ChildItem -LiteralPath $sourceRoot -File -Recurse -Force).Count
        $finalCount = @(Get-ChildItem -LiteralPath $final -File -Recurse -Force).Count
        if ($sourceCount -ne $finalCount) {
            throw "Runtime file-count mismatch: source=$sourceCount destination=$finalCount"
        }
        return $final
    }

    $stage = Join-Path $DestinationRoot (".repair-{0}-{1}" -f $Id, [guid]::NewGuid().ToString("N"))
    [IO.Directory]::CreateDirectory($stage) | Out-Null
    try {
        Get-ChildItem -LiteralPath $sourceRoot -Directory -Recurse -Force | ForEach-Object {
            $relative = $_.FullName.Substring($sourceRoot.Length).TrimStart("\")
            [IO.Directory]::CreateDirectory((Join-Path $stage $relative)) | Out-Null
        }
        Get-ChildItem -LiteralPath $sourceRoot -File -Recurse -Force | ForEach-Object {
            $relative = $_.FullName.Substring($sourceRoot.Length).TrimStart("\")
            Copy-PlainFile $_.FullName (Join-Path $stage $relative)
        }

        foreach ($relative in $DescriptorFiles) {
            Assert-SameFile (Join-Path $sourceRoot $relative) (Join-Path $stage $relative)
        }
        $sourceCount = @(Get-ChildItem -LiteralPath $sourceRoot -File -Recurse -Force).Count
        $stageCount = @(Get-ChildItem -LiteralPath $stage -File -Recurse -Force).Count
        if ($sourceCount -ne $stageCount) {
            throw "Runtime file-count mismatch: source=$sourceCount staging=$stageCount"
        }
        Move-Item -LiteralPath $stage -Destination $final
    }
    catch {
        if (Test-Path -LiteralPath $stage) {
            Remove-Item -LiteralPath $stage -Recurse -Force
        }
        throw
    }
    return $final
}

$windowsCli = Publish-FileBundle `
    $resources `
    (Join-Path $localRoot "bin") `
    $ids.WindowsCli `
    @(
        "codex.exe",
        "codex-code-mode-host.exe",
        "codex-windows-sandbox-setup.exe",
        "codex-command-runner.exe"
    )

$cuaNode = Publish-DirectoryBundle `
    (Join-Path $resources "cua_node") `
    (Join-Path $localRoot "runtimes\cua_node") `
    $ids.CuaNode `
    @("manifest.json", "bin/node.exe", "bin/node_repl.exe")

$windowsRg = Publish-FileBundle `
    $resources `
    (Join-Path $localRoot "bin") `
    $ids.WindowsRg `
    @("rg.exe")

$wslCli = Publish-FileBundle `
    $resources `
    $wslRoot `
    $ids.WslCli `
    @("codex", "codex-code-mode-host")

$wslRg = Publish-FileBundle `
    $resources `
    $wslRoot `
    $ids.WslRg `
    @("rg")

& (Join-Path $windowsCli "codex.exe") --version
& (Join-Path $cuaNode "bin\node.exe") --version
& (Join-Path $windowsRg "rg.exe") --version | Select-Object -First 1

[pscustomobject]@{
    PackageVersion = $pkg.Version.ToString()
    WindowsCli = $windowsCli
    CuaNode    = $cuaNode
    WindowsRg  = $windowsRg
    WslCli     = $wslCli
    WslRg      = $wslRg
} | Format-List

Write-Host "Recovery materialization completed for OpenAI.Codex $($pkg.Version). Start ChatGPT/Codex normally."

Validation from the recovered machine

Before recovery, the launch probe consistently reported:

Verdict: RED
Signals: BOOTSTRAP_FAILED, CLI_NOT_FOUND, RELOCATION_FAILED

After materializing the five version directories from the currently installed official package:

codex-cli 0.150.0-alpha.8
node v24.19.0
ripgrep 15.2.0
cua_node source files: 4018
cua_node cached files: 4018

The key bundle files matched the package sources by size and SHA-256. After relaunch:

hostId=local initialized=true next=connected
hostId=remote-ssh-codex-managed:WSL-Ubuntu initialized=true next=connected

The new launch logs no longer contained:

bundled_executable_relocation_failed
Unable to locate the Codex CLI binary
Desktop bootstrap failed
fatal_error_broadcasted

The desktop UI was also confirmed to launch normally.

Suggested upstream fix

Please make WindowsApps resource relocation support an Application Protected/EFS source and an ordinary decrypted per-user destination, for example by:

• using a Windows copy path equivalent to COPY_FILE_ALLOW_DECRYPTED_DESTINATION; or
• falling back to buffered read/write when the current copyFile receives ERROR_ENCRYPTION_FAILED;
• preserving the existing staging, SHA-256 validation, and atomic rename behavior;
• surfacing the underlying Win32 error instead of reporting every such failure as "CLI binary missing."

This remains a bundle-layout-specific temporary recovery. The script now recomputes the directory IDs from the installed package, so it can be rerun unchanged when an update changes only the version and resource bytes. It deliberately stops if the known file lists are no longer present. The durable fix belongs in the app's relocation implementation.

Related: #38696, #34764, #25571.