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

Activity

1. bevis7781

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Aug 25, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   app-serverIssues involving app server protocol or interfacesIssues involving app server protocol or interfaces

   on Aug 25, 2026
3. ahku667 commented on Aug 25, 2026

   

   ahku667

   on Aug 25, 2026 – with ChatGPT Codex Connector

   Last edited by ahku667

   More actions

   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.

   👍React with 👍4Reacted by GuangYing7771, Yibo Yuan, xiaodeng2025 and ranchon-q
4. hz3204323 commented on Aug 25, 2026

   

   hz3204323

   on Aug 25, 2026 – with ChatGPT Codex Connector

   More actions

   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.

   👍React with 👍2Reacted by GuangYing7771 and Yibo Yuan
5. xianlitijun commented on Aug 25, 2026

   

   xianlitijun

   on Aug 25, 2026 – with ChatGPT Codex Connector

   More actions

   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.

   👍React with 👍5Reacted by GuangYing7771, Yibo Yuan, Simon Syga, Lee and Z114-cpu
6. zemeng5208 commented on Aug 25, 2026

   

   zemeng5208

   on Aug 25, 2026 – with ChatGPT Codex Connector

   More actions

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

   👍React with 👍1Reacted by GuangYing7771
7. whywhybe commented on Aug 26, 2026

   

   whywhybe

   on Aug 26, 2026

   Last edited by whywhybe

   More actions

   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.
8. eksynn commented on Aug 26, 2026

   

   eksynn

   on Aug 26, 2026 – with ChatGPT Codex Connector

   More actions

   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:.

   👍React with 👍2Reacted by GuangYing7771 and Arttu Pitou At
9. pwnfan commented on Aug 26, 2026

   

   pwnfan

   on Aug 26, 2026

   Last edited by pwnfan

   More actions

   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.

   👍React with 👍5Reacted by hxlacceptedmsn, GuangYing7771, brian9866, mekeny and Ma Peijie
10. 981434631 commented on Aug 26, 2026

    

    981434631

    on Aug 26, 2026 – with ChatGPT Codex Connector

    More actions

    I can independently reproduce this exact startup regression on another Windows x64 machine.

    Environment

    • OpenAI.Codex: 26.820.7780.0
    • Windows: 10.0.26200.0 x64
    • Package status: Ok
    • Registered install location: C:\Program Files\WindowsApps\OpenAI.Codex_26.820.7780.0_x64__2p2nqsd0c76g0
    • Default AppX volume: F:\WindowsApps

    The packaged CLI exists at app\resources\codex.exe, but launching the desktop app fails with:

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

    On this machine:

    • the packaged codex.exe has attributes Archive, Encrypted;
    • a working copy under %LOCALAPPDATA%\OpenAI\Codex\bin\codex.exe has attributes Archive;
    • the packaged and user-directory copies are byte-identical by SHA-256:
      09D6723925E724EDF0BBBBC7B9E204526E0FB1462C86BD2A4997311FD5071EBA;
    • the copied CLI reports codex-cli 0.150.0-alpha.8.

    Reproduction / workaround confirmation

    1. With the user-level CODEX_CLI_PATH unset, relaunching immediately reproduces the fatal startup dialog.
    2. Copying the current package's four Windows CLI executables (codex.exe, codex-code-mode-host.exe, codex-windows-sandbox-setup.exe, and codex-command-runner.exe) into %LOCALAPPDATA%\OpenAI\Codex\bin\ succeeds when materialized as ordinary files.
    3. Setting the user-level variable to %LOCALAPPDATA%\OpenAI\Codex\bin\codex.exe allows Codex Desktop to start, and the running codex.exe process is the user-directory copy.

    This strongly supports the existing diagnosis: the bundled executable is present and valid, but the automatic WindowsApps-to-per-user relocation/materialization path fails. The generic “CLI binary missing” dialog is a downstream symptom.

    The environment-variable workaround restores the current release, but it bypasses automatic CLI discovery/relocation and can pin the desktop app to this copied CLI after a future update. Please fix the Windows relocation path (including encrypted/Application Protected package resources and cross-AppX-volume states), and surface the underlying copy error in the startup dialog.

    👍React with 👍1Reacted by GuangYing7771
11. xiaodeng2025 commented on Aug 26, 2026

    

    xiaodeng2025

    on Aug 26, 2026

    More actions

    I can independently reproduce this on Codex App 26.820.7780.0 / Windows 10.0.26200.0 x64.
    The bundled codex.exe exists, is marked Encrypted, and executing it directly returns Access is denied.
    The issue appeared immediately after updating. My duplicate report was #40762.
12. Daozhu1007 commented on Aug 26, 2026

    

    Daozhu1007

    on Aug 26, 2026

    More actions

    Adding a few data points from my machine (26.820.7780.0, Windows 11 10.0.26200 x64) that may help triage:

    1. This relocation step has been flaky since at least Aug 18 — the update just made it fatal.

    My desktop logs show bundled_executable_relocation_failed (same errno=-4094 / UNKNOWN / copyfile) intermittently on Aug 18, 22, 23, 24 and 25, while the app still started fine — the previously relocated binary in %LOCALAPPDATA%\OpenAI\Codex\bin was still present, so the failed relocation only logged a warning. After updating to 26.820.7780.0 the app no longer accepted the old binary and attempted a fresh relocation, which failed, leaving no binary at all. There seems to be no fallback when bin\codex.exe is missing.

    2. CopyFileW hangs on the packaged binaries; a plain read/write stream copy works.

    app\resources\codex.exe shows the Archive, Encrypted attributes here too (confirming @xiaodeng2025's observation). One caveat: the successfully-relocated April-era binary also carries Archive, Encrypted, so the attribute alone doesn't explain why relocation used to succeed. But the CopyFileW behavior is clearly broken: the app's fs.copyFile fails with -4094, and PowerShell Copy-Item on an 8 MB packaged exe hangs indefinitely (>90 s, never completes). A stream copy that doesn't go through CopyFileW ([IO.File]::OpenRead + CopyTo, or cp in Git Bash) completes in under a second and produces a hash-identical, working binary with the Encrypted attribute cleared.

    So a possible app-side fix: when the copyfile relocation fails, fall back to a read/write stream copy — that would make relocation robust regardless of the underlying cause.

    3. Verified recovery (no rollback, no permission changes):

    $src = Join-Path (Get-AppxPackage OpenAI.Codex).InstallLocation 'app\resources'
    $dst = "$env:LOCALAPPDATA\OpenAI\Codex\bin"
    New-Item -ItemType Directory -Force -Path $dst | Out-Null
    'codex.exe','codex-code-mode-host.exe','codex-command-runner.exe','codex-windows-sandbox-setup.exe','rg.exe' | ForEach-Object {
      $in = [IO.File]::OpenRead("$src\$_"); $out = [IO.File]::Create("$dst\$_"); $in.CopyTo($out); \$in.Close(); $out.Close()
    }
    [Environment]::SetEnvironmentVariable('CODEX_CLI_PATH', "$dst\codex.exe", 'User')

    After this the app starts normally: zero fatal errors in the desktop log, app_server_connection reaches connected/initialized=true, and the running codex.exe is confirmed to be the manually placed copy.

    👍React with 👍3Reacted by GuangYing7771, haru and Limitime
13. liangjxiong commented on Aug 26, 2026

    

    liangjxiong

    on Aug 26, 2026 – with ChatGPT Codex Connector

    More actions

    Another exact reproduction on OpenAI.Codex 26.820.7780.0 x64.

    Environment/audit:

    • Registered install location: C:\Program Files\WindowsApps\OpenAI.Codex_26.820.7780.0_x64__2p2nqsd0c76g0...
    • No separate ChatGPT AppX package is returned by Get-AppxPackage *ChatGPT*.
    • Persistent CODEX_CLI_PATH is unset at both User and Machine scopes.
    • ~/.codex/config.toml contains no runCodexInWindowsSubsystemForLinux, integratedTerminalShell, CODEX_CLI_PATH, or sandbox-bin override.

    There had previously been a process-local workaround value pointing at %USERPROFILE%\.codex\.sandbox-bin\codex.exe; removing it clears the environment variable. That workaround could allow the desktop app to get further/start, but then Codex was unable to reliably modify project files/code. The desktop global state still contains the expected project roots under thread-writable-roots, including the affected project directories, so this does not look like a simple missing writable-root grant.

    This strongly matches #40700 rather than a WSL-only configuration problem. It also suggests that setting CODEX_CLI_PATH to a manually staged .sandbox-bin\codex.exe is not a safe workaround because it may create a desktop/runtime/sandbox mismatch even if startup succeeds.
14. 24 remaining items

    Load more

15. bherreraicon commented on Aug 27, 2026

    

    bherreraicon

    on Aug 27, 2026 – with ChatGPT Codex Connector

    More actions

    Confirmed workaround on Windows 11 for the Unable to locate the Codex CLI binary regression.

    Environment:

    • OpenAI.Codex 26.820.10647.0
    • Windows 11 build 26200
    • Native CLI found under %LOCALAPPDATA%\OpenAI\Codex\bin\...\codex.exe
    • CLI reported codex-cli 0.150.0-alpha.8

    Observed behavior:

    • Desktop failed at startup with Unable to locate the Codex CLI binary.
    • %LOCALAPPDATA%\OpenAI\Codex\bin contained many .staging-* directories.
    • A non-staging hash directory containing codex.exe appeared, but during subsequent startup attempts that directory could be rotated/removed, so pointing CODEX_CLI_PATH directly at that managed hash directory was not stable.

    Workaround that successfully started Codex Desktop:

    # Find a working native codex.exe
    $CodexSource = Get-ChildItem "$env:LOCALAPPDATA\OpenAI\Codex\bin" -Recurse -Filter "codex.exe" -ErrorAction SilentlyContinue |
        Where-Object { $_.FullName -notmatch '\\.staging-' } |
        Select-Object -First 1 -ExpandProperty FullName
    
    # Verify it works
    & $CodexSource --version
    
    # Copy it outside the updater-managed Codex\bin tree
    New-Item -ItemType Directory -Force "$env:LOCALAPPDATA\OpenAI\CodexCLI" | Out-Null
    Copy-Item $CodexSource "$env:LOCALAPPDATA\OpenAI\CodexCLI\codex.exe" -Force
    
    # Verify the stable copy
    & "$env:LOCALAPPDATA\OpenAI\CodexCLI\codex.exe" --version
    
    # Persist the path for the Desktop app
    [Environment]::SetEnvironmentVariable(
        "CODEX_CLI_PATH",
        "$env:LOCALAPPDATA\OpenAI\CodexCLI\codex.exe",
        "User"
    )

    Then fully close ChatGPT/Codex processes and reopen Codex normally from Start.

    This worked for me. Copying the executable outside %LOCALAPPDATA%\OpenAI\Codex\bin was important because the hash directory inside that tree was modified/removed by subsequent startup/update attempts. This is only a temporary workaround until the relocation/updater issue is fixed; the copied CLI can become stale after future updates.
16. ZzXxYy1234 commented on Aug 28, 2026

    

    ZzXxYy1234

    on Aug 28, 2026

    More actions

    Also reproduces on the two builds after the one reported here, with new root-cause detail and a reliable workaround.

    Versions: 26.820.9563.0 and 26.825.3734.0 (Store auto-update), Windows 11 10.0.26200 x64

    Symptom variant (headless window): processes spawn but no window is ever created; the main process busy-spins (58+ CPU-seconds) for ~8 minutes; the desktop log stops right after Appshot hotkey inactive. During this state the app repeatedly creates .staging-<hash>-* directories under %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\ that stall at ~3600/4680 files, get cleaned up, and are recreated — matching bundled_executable_relocation_failed ... errno=-4094 code=UNKNOWN syscall=copyfile in the log. On 26.820.9563.0 the loop eventually succeeded and the window appeared (startupElapsedMs≈15600); on 26.825.3734.0 it did not recover on its own within 40+ minutes.

    Two independent failure modes in the relocation step:

    1. EFS-encrypted package resources (see also [Windows][WSL] MSIX EFS-encrypted bundled codex fails relocation with ERROR_ENCRYPTION_FAILED (0x80071770) #38696): every file under C:\Program Files\WindowsApps\OpenAI.Codex_<ver>_x64__2p2nqsd0c76g0\app\resources carries the NTFS Encrypted attribute on affected machines ((Get-Item ...).Attributes → Archive, Encrypted). On accounts where EFS cannot initialize (cipher /k → "The request is not supported"), CopyFileW-based copies fail with ERROR_ENCRYPTION_FAILED ("cannot encrypt the specified file") because CopyFileW preserves the Encrypted attribute on the destination. robocopy fails the same way; plain read→write copies of the same files succeed.
    2. Paths > MAX_PATH: resources\cua_node contains pnpm-store directory trees deeper than 260 characters; with LongPathsEnabled=0 even Get-ChildItem -Recurse errors on them, so the relocation copy cannot enumerate the full tree.

    Workaround that reliably unblocks startup (~15 s): pre-create the relocation destination so the app skips its own copy:

    • <hash> = the hash from the leftover %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\.staging-<hash>-* directory name (e.g. 759ccb73c5d75f83 for 26.825.3734.0);
    • stream-copy ...\app\resources\cua_node → %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<hash>\ with anything that does not preserve attributes (e.g. Node fs.readFileSync/fs.writeFileSync — 4680 files / ~319 MB, 0 failures);
    • kill ChatGPT.exe and relaunch.

    (For the earlier "Unable to locate the Codex CLI binary" dialog variant on .7780: setting CODEX_CLI_PATH to a real codex.exe worked — note that pointing it at the npm codex.cmd shim fails with spawn EINVAL.)

    Suggestions:

    • strip the Encrypted attribute from packaged resources, or document why Store-delivered packages end up EFS-encrypted on some machines;
    • use \\?\-prefixed (long-path-aware) paths in the relocation routine;
    • treat relocation failure as non-fatal with bounded retries and a visible error — falling back to executing the bundled binaries directly from the package path would dodge both failure modes.
17. suizhejiu commented on Aug 28, 2026

    

    suizhejiu

    on Aug 28, 2026

    More actions

    Still reproduces on 26.825.4187.0 (Store auto-update chain) — the bug survives patch updates and recurs after every update.

    Environment:

    • OpenAI.Codex 26.825.4187.0 x64
    • Windows 11, MSIX/Store install
    • Symptom identical: app processes spawn but no GUI window is ever created (all MainWindowHandle = 0; only MAIN/GPU/UTILITY/CRASHPAD child processes, no --type=renderer, no codex.exe backend)
    • app\resources\codex.exe still reports Archive, Encrypted / Application Protected; direct execution from WindowsApps = Access is denied; fs.copyFile-style relocation fails with ERROR_ENCRYPTION_FAILED (0x80071770)

    Key observations for maintainers:

    1. This is a per-update recurring break: 26.820.9563.0 -> 26.825.3734.0 -> 26.825.4187.0 all fail the same way. Each Store update changes the resource hashes, so the previously-relocated per-user cache directory (%LOCALAPPDATA%\\OpenAI\\Codex\\bin\\<16-hex-hash>) no longer matches, and the app tries to relocate again and fails. Users who applied the earlier workaround are re-broken on every update.
    2. The recovery that works (no rollback, no WindowsApps ACL/ownership changes, no CODEX_CLI_PATH pointing into WindowsApps):
       • Materialize the bundled executables into the per-user cache using a plain buffered read/write stream copy (FileStream.CopyTo), which bypasses the EFS/Application-Protected copy failure that CopyFileW/fs.copyFile hits. Destination must be created as an ordinary (unencrypted) file.
       • Directory name is computed from the package descriptors (<UTF-8 file name> NUL <lowercase SHA-256> NUL concatenated, then SHA-256 of the whole descriptor, first 16 hex chars) — this needs to be recomputed per version.
       • Then set user env var CODEX_CLI_PATH to %LOCALAPPDATA%\\OpenAI\\Codex\\bin\\<hash>\\codex.exe. The app honors it (app.asar contains CODEX_CLI_PATH handling).
       • After that the desktop starts normally: renderer processes spawn and the backend codex.exe runs from the per-user cache.
    3. cua_node directory relocation also fails (copy_directory) — node runtime unavailable in the affected path even after the CLI workaround.

    Please fix the Windows relocation path to handle an Application-Protected/EFS source with an ordinary decrypted destination (e.g. COPY_FILE_ALLOW_DECRYPTED_DESTINATION or a buffered read/write fallback on ERROR_ENCRYPTION_FAILED), and ideally preserve/validate existing per-user caches across updates so the app does not re-break on every Store update. Happy to provide more logs/hashes if helpful.
18. Jiaoyang45 commented on Aug 31, 2026

    

    Jiaoyang45

    on Aug 31, 2026

    Last edited by Jiaoyang45

    More actions

    Still reproduces on 26.825.6671.0, but the bundled resources are not marked Encrypted

    I can reproduce the same startup failure on a newer Store build:

    • OpenAI.Codex 26.825.6671.0 x64
    • Windows, Microsoft Store/MSIX installation
    • Startup error:

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

    I ran a read-only diagnostic check before applying any workaround.

    Package and AppX volume

    Name              : OpenAI.Codex
    Version           : 26.825.6671.0
    Status            : Ok
    IsPartiallyStaged : False
    InstallLocation   : C:\Program Files\WindowsApps\OpenAI.Codex_26.825.6671.0_x64__2p2nqsd0c76g0
    

    The package is physically installed on the system AppX volume:

    PackageStorePath             IsSystemVolume Version
    ----------------             -------------- -------
    C:\Program Files\WindowsApps True           26.825.6671.0
    

    Therefore, this machine does not have the secondary/non-system AppX volume configuration reported by some other affected users.

    Bundled executables exist and are not encrypted

    The expected files are present under app\resources:

    Name                               Length      Attributes
    ----                               ------      ----------
    codex.exe                          313790256   Archive
    codex-code-mode-host.exe            72301360   Archive
    codex-command-runner.exe             8196912   Archive
    codex-windows-sandbox-setup.exe     15414064   Archive
    rg.exe                               4234544   Archive
    cua_node                                        Directory
    

    Unlike the earlier EFS/Application Protected cases in this issue, these resources report only Archive, not Archive, Encrypted.

    No CLI override or PATH installation

    CODEX_CLI_PATH is empty at both User and Machine scope:

    User CODEX_CLI_PATH    = <empty>
    Machine CODEX_CLI_PATH = <empty>
    

    There is also no standalone Windows Codex CLI currently available through PATH:

    where.exe codex
    INFO: Could not find files for the given pattern(s).
    

    Relocation/cache evidence

    %LOCALAPPDATA%\OpenAI\Codex\bin contains a very large number of abandoned .staging-<hash>-* directories from repeated startup attempts.

    New staging directories were created during the latest attempts on August 31, for example:

    .staging-b99306303521e97e-DqXK9C
    .staging-b99306303521e97e-Mz8tFY
    .staging-d664d99528113e03-LboLQc
    

    Some older non-staging cache directories and executables also exist, but the current Desktop build still reports that it cannot locate the CLI.

    The CUA runtime appears to have reached a finalized, non-staging directory:

    %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\415ffebf3d576e9b
    

    This suggests that, on this machine, the immediate startup blocker is specifically the CLI relocation/cache finalization path.

    Conclusion

    This appears to be a new variant of the same bundled-runtime relocation problem:

    • the package is healthy;
    • it is installed on the system C: AppX volume;
    • the bundled codex.exe exists;
    • the bundled resources are not marked Encrypted;
    • CODEX_CLI_PATH is not misconfigured;
    • but Desktop repeatedly creates .staging-* directories and fails to produce or select a usable current CLI cache.

    This suggests the issue may be broader than EFS encryption or installation on a secondary AppX volume. There may also be a failure in staging-directory promotion, cache validation, file locking, or another part of the relocation path.

    I have not modified WindowsApps permissions, reset the app, deleted the runtime caches, installed a standalone Windows CLI, or set CODEX_CLI_PATH, so the failing state is currently preserved.

    I can provide the relevant Desktop startup logs or run additional read-only diagnostics if that would help identify the exact failed operation and Windows error code.

    @etraut-openai
19. eksynn commented on Aug 31, 2026

    

    eksynn

    on Aug 31, 2026 – with ChatGPT Codex Connector

    More actions

    Hey, this appears fixed for me in 26.825.6671.0 xD

    The Microsoft Store auto-updated the desktop app while I wasn't looking, and it is now starting and working normally on my machine. I had previously rolled back to 26.818.8289.0 because 26.820.7780.0 failed at startup.

    This is one machine's result rather than confirmation that it is fixed for everyone, especially since another report here still reproduces it on the same build.
20. yashuamao commented on Sep 1, 2026

    

    yashuamao

    on Sep 1, 2026

    Last edited by yashuamao

    More actions

    Independent recurrence on a Windows Microsoft Store/MSIX installation, confirming that the failure persists across later 26.825 updates.

    Version/update history

    • 26.820 family: first fatal startup failure
    • 26.825.4187: failure recurred after Store update
    • 26.825.5331: failure recurred after Store update
    • Current package: OpenAI.Codex 26.825.6671.0 x64

    The original fatal dialog was:

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

    A version-specific CODEX_CLI_PATH workaround restored startup, but each Store update replaced the versioned package directory, making the previous absolute path stale and causing the failure to recur.

    Read-only findings on 26.825.6671.0

    • app\resources\codex.exe exists (313,790,256 bytes).
    • app\resources\bin\codex and app\resources\bin\codex.exe do not exist.
    • The working app process currently has a process-local CODEX_CLI_PATH pointing to the current package's app\resources\codex.exe; User and Machine scope values are unset.
    • The current Sentry breadcrumb still repeatedly records a related protected-resource copy failure:

    [BundledPluginsMarketplace] plugin_marketplace_folder_write_failed
    errorCode=UNKNOWN
    errorMessage="UNKNOWN: unknown error, copyfile '<WindowsApps package>\app\resources\plugins\openai-bundled\plugins\sites\.app.json' -> '<CODEX_HOME>\.tmp\bundled-marketplaces\...\plugins\sites\.app.json'"
    stack: node:internal/fs/promises:619:10
    

    This shows that the Windows packaged-resource copyfile path is still failing in 26.825.6671.0, now visibly affecting bundled-plugin materialization as well as the earlier CLI/runtime relocation path. CODEX_HOME is on a separate NTFS volume in this reproduction; all usernames and absolute user paths are intentionally omitted.

    Requested fix

    Please make bundled-resource relocation compatible with Application Protected/encrypted MSIX sources (for example, a buffered read/write fallback instead of relying only on copyfile), use a stable per-user runtime resolution path, and avoid requiring a CODEX_CLI_PATH value that embeds the Store package version. The downstream “CLI binary missing” dialog should also surface the underlying relocation/copy error.

    No WindowsApps ownership, ACL, or package-file modifications were used for these findings.
21. xiaodeng2025 commented on Sep 1, 2026

    

    xiaodeng2025

    on Sep 1, 2026

    More actions

    不是修复了吗 为啥还没关闭
22. bevis7781 commented on Sep 1, 2026

    

    bevis7781

    on Sep 1, 2026

    Author

    More actions

    Update from the original reporter:

    26.825.6671.0 now starts and works normally on my previously affected machine.

    My history/projects are intact, a new local task works normally, and the app also starts successfully after a full quit and relaunch. I did not use CODEX_CLI_PATH, manual runtime materialization, or WindowsApps ACL changes.

    For reference, this same machine previously failed on 26.820.7780.0 and later 26.825.4187.0, so this is a meaningful improvement for my environment.

    I’m leaving the issue open for now because other users are still reporting the same or related bootstrap/materialization failures on 26.825.6671.0. So this appears fixed for at least some previously affected systems, but not yet universally resolved.
23. pieyixi commented on Sep 2, 2026

    

    pieyixi

    on Sep 2, 2026

    More actions

    Update from the same affected Windows machine:

    I tested Codex Desktop 26.831.1445.0 after removing my CODEX_CLI_PATH workaround.

    The good news is that the original startup blocker appears to be fixed on this machine. Codex Desktop now successfully materializes and launches the official runtime from:

    %LOCALAPPDATA%\OpenAI\Codex\bin\7537f22ba194f7c1\codex.exe
    

    The app-server reports:

    currentVersion=0.152.0
    

    So the previous failure where the bundled Codex runtime could not be relocated out of WindowsApps no longer prevents Desktop from starting.

    However, the underlying Application Protected file-copy problem does not appear to be fully resolved. It now reproduces while Codex Desktop is copying the bundled plugin marketplace.

    The log repeatedly reports:

    plugin_marketplace_folder_write_failed
    bundled_plugins_marketplace_resolve_failed
    

    For example, it attempts to copy:

    C:\Program Files\WindowsApps\OpenAI.Codex_26.831.1445.0_x64__2p2nqsd0c76g0\app\resources\plugins\openai-bundled\plugins\sites\.app.json
    

    to:

    %USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled.staging-...\plugins\sites\.app.json
    

    The stack trace goes through Node's copyFile / fs.cp.

    I checked the source file with cipher /c, and Windows reports:

    E .app.json
    Compatibility Level: Application Protected
    

    The failed marketplace copies also leave staging directories behind. There are currently 32 openai-bundled.staging-* directories under:

    %USERPROFILE%\.codex\.tmp\bundled-marketplaces
    

    They contain various partially copied plugins such as browser, chrome, computer-use, latex, sites, and visualize.

    Startup is now successful but relatively slow. In this launch, the log reported approximately:

    window main frame finished load: startupElapsedMs=6164
    Host startup critical-path phases completed: startupElapsedMs=20502
    

    Current result:

    26.831.1445.0 fixes the original runtime-relocation startup blocker on this machine, but Application Protected files can still fail when copied from WindowsApps through the bundled-plugin marketplace path.

    This looks like the same underlying protected-file copy compatibility issue occurring in another copy path.
24. sakimarquis commented on Sep 6, 2026

    

    sakimarquis

    on Sep 6, 2026

    More actions

    不是修复了吗 为啥还没关闭

    my computer still cannot open codex
25. Daozhu1007 commented on Sep 7, 2026

    

    Daozhu1007

    on Sep 7, 2026

    More actions

    PSA for anyone using the manual-copy workaround from this thread: the copy goes stale silently.

    After the 26.901.6511 update, our Aug-26 copy (0.150.0-alpha.8) kept serving for days, and the server-side model gate (GPT-6 Astra needs client_version ≥ 0.153.0) made the new model invisible in the desktop picker — even though the installed package bundles 0.153.4. Restarting doesn't help; you must refresh the copy in %LOCALAPPDATA%\OpenAI\Codex\bin\.

    Details and verified fix in #42853.
26. DDXG commented on Sep 10, 2026

    

    DDXG

    on Sep 10, 2026

    More actions

    Additional reproduction: non-ASCII Windows profile and CODEX_HOME workaround

    I would like to add a Windows reproduction involving a non-ASCII user profile path.

    Environment

    • Windows 10 Pro x64, build 19044
    • User profile contains Chinese/non-ASCII characters:

    C:\Users\<ChineseUsername>
    

    • Current Desktop package observed:

    OpenAI.Codex_26.903.8094.0_x64__2p2nqsd0c76g0
    

    Background

    Because Codex Desktop has path compatibility problems when the Windows user profile contains Chinese/non-ASCII characters, I intentionally keep the Codex state directory on an ASCII-only path:

    CODEX_HOME=D:\codex-home
    

    This is a deliberate long-term compatibility workaround, not an arbitrary data relocation. I need to keep CODEX_HOME outside the Windows profile to avoid reintroducing the non-ASCII path problem.

    The Chromium/Web user-data directory remains under the normal Windows profile:

    C:\Users\<ChineseUsername>\AppData\Roaming\Codex\web\Codex
    

    This directory serves a different purpose from CODEX_HOME.

    Timeline

    My own incident involved two different startup failure modes at different stages.

    1. First immediate startup failure: 2026-08-26

    After a Desktop update, the application immediately failed to start with:

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

    The affected Desktop version was recorded as:

    26.820.7780.0
    

    The package contained:

    app\resources\codex.exe
    

    However, executing the bundled executable directly from WindowsApps failed with Access Denied. A normal copy operation from the WindowsApps package also failed with an encryption/file-attribute error.

    I copied the executable contents to an external ASCII-only directory without preserving the WindowsApps/MSIX file attributes. The copied executable ran successfully and reported:

    codex-cli 0.150.0-alpha.8
    

    I then configured:

    CODEX_HOME=D:\codex-home
    CODEX_CLI_PATH=D:\codex-home\bin\codex.exe
    

    This restored Desktop startup.

    2. Later multi-minute startup delay

    After a later Desktop update, the application could start, but ChatGPT.exe and multiple child processes appeared immediately while the foreground window took several minutes to appear.

    During this period, one process continuously consumed CPU, memory and disk resources. The application was not completely idle and appeared to be performing initialization, probing or retrying some operation.

    3. Second immediate startup failure during troubleshooting: 2026-09-10

    While troubleshooting the multi-minute startup delay, CODEX_CLI_PATH was modified/removed.

    CODEX_HOME remained:

    D:\codex-home
    

    However, the User-level CODEX_CLI_PATH became empty. The application immediately failed again with:

    ChatGPT failed to start.
    
    Unable to locate the Codex CLI binary or required runtime components.
    Check the installation or explicit runtime overrides.
    

    The external executable was independently verified with:

    & "D:\codex-home\bin\codex.exe" --version

    After restoring:

    CODEX_CLI_PATH=D:\codex-home\bin\codex.exe
    

    and restarting ChatGPT Desktop, the same Desktop installation started normally again. Startup returned from several minutes to only a few seconds.

    Confirmed behavior

    • Removing CODEX_CLI_PATH causes an immediate fatal startup failure in this environment.
    • Restoring a valid external CLI path restores startup.
    • After some Desktop updates, CLI/runtime discovery or fallback behavior can cause a multi-minute startup delay.
    • It is not yet proven that the CLI version alone causes the delay; the behavior may involve CLI discovery, relocation, version selection or retry/timeout logic.
    • The problem is especially relevant when the Windows profile contains non-ASCII characters and CODEX_HOME is redirected to an ASCII-only path.

    Expected behavior

    • Desktop should reliably locate or stage the bundled CLI after every update.
    • An ASCII-only CODEX_HOME should be fully supported as a workaround for non-ASCII Windows profile paths.
    • Existing CODEX_HOME and CODEX_CLI_PATH configurations should not regress after an update.
    • If CLI/runtime discovery fails, Desktop should fail fast with a precise diagnostic instead of spending several minutes retrying.
    • Users should not need to manually extract a CLI after every update.
    • Desktop should automatically use the CLI matching the installed Desktop version, or clearly report a version mismatch.

    Current workaround

    CODEX_HOME=D:\codex-home
    CODEX_CLI_PATH=D:\codex-home\bin\codex.exe
    

    The external CLI must be copied outside WindowsApps without preserving the protected MSIX file attributes. This workaround restores startup, but it is fragile because the copied CLI may become stale after a Desktop update.

    Please investigate the interaction between WindowsApps protected-file relocation, non-ASCII Windows profile paths, CODEX_HOME, CODEX_CLI_PATH, CLI version selection and the startup retry/fallback logic.
27. vietnd69 commented on Sep 10, 2026

    

    vietnd69

    on Sep 10, 2026

    More actions

    Confirming that this issue still reproduces on a newer Codex Desktop release.

    Environment

    • Codex Desktop: 26.903.8094.0
    • Bundled CLI: codex-cli 0.153.4
    • Windows x64
    • Microsoft Store/MSIX package stored on a secondary NTFS AppX volume (D:)

    Current reproduction

    After updating Codex, the current staging directory under %LOCALAPPDATA%\OpenAI\Codex\bin\<hash> contained only rg.exe. These packaged executables existed under app\resources but were not relocated:

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

    Windows App Repair and a full restart did not rebuild the staged runtime.

    A CODEX_CLI_PATH workaround from the previous affected release was still pointing to codex-cli 0.150.0-alpha.8. Consequently, Desktop used the stale CLI with the newer app and sandboxed commands failed before execution:

    orchestrator_helper_launch_failed:
    setup refresh failed to launch helper:
    helper=codex-windows-sandbox-setup.exe
    error=program not found
    

    The helper was present inside the new MSIX package, but absent from the active staged directory and not discoverable through PATH.

    Workaround and validation

    I used raw buffered stream copies, rather than the normal encrypted-file-preserving copy operation, to relocate the complete 0.153.4 executable set to a user-writable directory on D:. SHA-256 hashes were verified against the packaged files.

    I then updated CODEX_CLI_PATH and PATH to use that complete, version-matched directory.

    After restarting Windows:

    • The Codex app-server runs from the relocated 0.153.4 directory.
    • codex-windows-sandbox-setup.exe and codex-command-runner.exe resolve correctly.
    • A direct Windows sandbox smoke test succeeds.
    • Normal sandboxed shell commands succeed.
    • The standard file-editing tool can create, read, and delete a workspace file.

    This indicates that the packaged binaries are valid and the failure remains in the WindowsApps/Application Protected relocation and staging path. It also shows that partial staging can leave Desktop pinned to an older CLI and cause secondary sandbox-helper failures.

    The product fix should ideally:

    1. Retry relocation with a decrypted-destination or buffered stream-copy path when Windows surfaces the encryption failure as UNKNOWN / -4094.
    2. Validate and atomically publish the complete executable group, rather than accepting a staging directory containing only rg.exe.
    3. Resolve sandbox helpers relative to the selected CODEX_CLI_PATH, or ensure that the matching helper directory is added to PATH.
    4. Rebuild stale or incomplete staged runtimes during Windows App Repair.
28. suizhejiu commented on Sep 13, 2026

    

    suizhejiu

    on Sep 13, 2026

    More actions

    Follow-up: the cross-volume AppX layout looks like the underlying mechanism on this class of machine. Moving the package to the system volume eliminated both the relocation failure and the follow-on failures entirely.

    (Previously reported here on 26.825.4187.0; reproduced since on 26.820.9563.0, 26.825.3734.0, 26.825.5331.0, 26.901.5280.0, 26.901.6511.0, and now diagnosed on 26.903.9818.0.)

    Key observation: the package directory was a cross-volume junction

    InstallLocation : C:\Program Files\WindowsApps\OpenAI.Codex_26.903.9818.0_x64__2p2nqsd0c76g0
    LinkType        : Junction
    Target          : D:\WindowsApps\OpenAI.Codex_26.903.9818.0_x64__2p2nqsd0c76g0
    
    Get-AppxVolume:
    PackageStorePath                 IsSystemVolume
    C:\Program Files\WindowsApps     True      <- system volume
    D:\WindowsApps                   False     <- where the package actually lived
    

    The app's user-data path was also a reparse point, and the desktop log contained EXDEV: cross-device link not permitted on renames that appear to be inside a single directory.

    Failure chain observed (one machine, same version)

    1. bundled_executable_relocation_failed — the packaged codex.exe group never reached %LOCALAPPDATA%\OpenAI\Codex\bin\<hash>; no codex.exe backend spawns, so processes run but no window is ever created (same phenotype as Windows app launches background Electron processes but never spawns codex.exe or creates a window #41125).
    2. plugin_marketplace_folder_write_failed / bundled_plugins_marketplace_resolve_failed — copying app\resources\plugins\openai-bundled out of the package failed on every window focus (copyfile ... UNKNOWN), leaving a partial marketplace (7 of 10 descriptors).
    3. Every configured MCP server (codex_app, freecad, blender, memslides, desktop_automation) hit timed out after 30 seconds during startup.
    4. After running for a while the UI returned answers but stayed stuck in the "Thinking" state with a non-functional stop control — consistent with the frontend query lifecycle being blocked behind the repeated reconcile/copy failures.

    What fixed it

    # Fully quit Codex first.
    $pkg = Get-AppxPackage OpenAI.Codex
    $vol = Get-AppxVolume | Where-Object IsSystemVolume
    Move-AppxPackage -Package $pkg.PackageFullName -Volume $vol

    (or Settings → Apps → Installed apps → ChatGPT → Move → C:)

    Then: verified Get-Item $pkg.InstallLocation -Force | Select-Object LinkType is empty (no longer a junction), removed the CODEX_CLI_PATH override, deleted the manually materialized %LOCALAPPDATA%\OpenAI\Codex\bin\<hash> caches, and launched normally.

    Before → after (same machine and package version)

    Signal	Before	After
    bundled_executable_relocation_failed	every launch	0
    App materializes its own runtime	never	succeeds, recreates bin\<hash> unaided
    CODEX_CLI_PATH workaround	required	not needed
    plugin_marketplace_folder_write_failed	every focus	0
    MCP startup timeouts	all servers	0
    EXDEV on renames	present	0

    Because the app now stages its own runtime, the "the manual copy goes stale after every Store update" problem described by @Daozhu1007 (hit here across six consecutive updates) no longer applies.

    Supporting signals from elsewhere in the tracker

    • @vietnd69 reports the same staging failure on 26.903.8094.0 and notes the package was stored on a secondary NTFS AppX volume (D:), which is consistent with this.
    • [Windows] Archiving Codex tasks fails with ERROR_NOT_SAME_DEVICE (os error 17) #36289 reports ERROR_NOT_SAME_DEVICE (os error 17) from the archive flow while the standard session root and archive root are on the same volume — a cross-volume package/link layout would explain a move that crosses devices despite same-volume session roots.
    • Earlier in this thread @Drifter-rookie and @Agony-frank reported that moving the app back to C: restored startup; this adds the mechanism plus before/after measurements.

    Scope — what this does and does not claim

    • One machine, verified by measurement. This is not a claim that every report in this thread shares this cause; a single-volume install can still fail purely on the EFS/Application-Protected copy path.
    • Moving volumes does not fix the EFS copy path. After the move, bundled-plugin materialization still fails on individual files (plugins\browser\.codex-plugin\plugin.json, plugins\unified-computer-use\.codex-plugin\plugin.json), leaving 7 of 10 bundled plugins (deep-research, sites, user-writing absent). The decrypted-destination / buffered-copy fallback proposed by @pwnfan and @vietnd69 is still needed.
    • No WindowsApps ACLs, ownership, package files, or encryption attributes were changed. config.toml contents and credentials are deliberately excluded.

    Suggested product fixes

    1. Use a relocation path that survives both cases: COPY_FILE_ALLOW_DECRYPTED_DESTINATION or a buffered read/write fallback on ERROR_ENCRYPTION_FAILED / -4094, and stage into a temporary location on the same volume as the destination before publishing.
    2. Validate and atomically publish the complete executable group instead of accepting a partial staging directory (e.g. only rg.exe).
    3. Rebuild incomplete staged runtimes during Windows App Repair.
    4. Detect a non-system AppX volume for the package on startup and surface it, since the resulting reparse-point layout otherwise fails silently.

    Diagnostics for anyone hitting this

    # Is the package on a secondary volume / reached through a junction?
    Get-AppxPackage OpenAI.Codex | Select-Object InstallLocation
    Get-Item (Get-AppxPackage OpenAI.Codex).InstallLocation -Force | Select-Object FullName, LinkType, Target
    Get-AppxVolume | Select-Object PackageStorePath, IsSystemVolume
    
    # Is the staged runtime complete?
    Get-ChildItem "$env:LOCALAPPDATA\OpenAI\Codex\bin"
    
    # Relocation / copy / timeout failures in the newest desktop log
    Get-ChildItem "$env:LOCALAPPDATA\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs" -Recurse -File |
      Sort-Object LastWriteTime -Descending | Select-Object -First 1 |
      Get-Content |
      Select-String 'bundled_executable_relocation_failed|plugin_marketplace_folder_write_failed|EXDEV|timed out after'

    If LinkType reports Junction with a target outside the system volume, moving the package to the system volume is worth trying before applying caching workarounds.
29. kilia commented on Oct 15, 2026

    

    kilia

    on Oct 15, 2026

    More actions

    Same Problem.

    The root cause of this issue is that the runtime files failed to copy during the Codex auto-update, resulting in a mismatch between the old and new hash-based cache paths, which prevented the organization settings from loading.

    you can fix this issue by ask codex cli to fix according to current issue url(#40700)