[Windows] Desktop startup repeatedly fails with EPERM during bundled executable rename_staging; succeeds after ProcMon changes timing

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

26.908.9136.0

What subscription do you have?

Plus

What platform is your computer?

No response

What issue are you seeing?

Environment

• OS: Windows 11 x64
• Application: OpenAI ChatGPT / Codex Desktop for Windows
• Affected versions reproduced:
  • 26.903.9818.0
  • 26.908.9136.0
• Package:
  • OpenAI.Codex
  • Latest reproduced PackageFullName:
    OpenAI.Codex_26.908.9136.0_x64__2p2nqsd0c76g0
• Installation source: Windows packaged application / WindowsApps
• Latest runtime deployment hash:
  12219cbfbcbddde7

Problem

ChatGPT / Codex Desktop repeatedly failed to start on Windows with the following generic error:

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

After extensive diagnostics, the generic "Unable to locate the Codex CLI binary" message appears to be a downstream symptom rather than the actual root failure.

The actual bootstrap failure occurs while the desktop application attempts to relocate the bundled codex.exe from a temporary .staging-* directory into its final hash-named runtime directory.

The relocation repeatedly fails at the rename_staging operation with Windows EPERM.

Importantly, the issue reproduced across two different application versions, including after a complete uninstall, deletion of the local runtime directory, reboot, and clean reinstall.

Eventually, while Process Monitor (ProcMon) was being used to investigate the filesystem operation, the exact same installation suddenly completed the relocation successfully.

After the final runtime directory was successfully created, the application was restarted three times and all three launches succeeded.

This suggests a timing-sensitive race / transient file-handle contention during the Windows bundled executable relocation process rather than a permanently missing executable or static filesystem permission problem.

Reproduction

The issue occurred repeatedly with the following sequence:

1. Install or update ChatGPT / Codex Desktop on Windows.

2. Ensure that the local Codex runtime needs to be deployed.

3. Launch the application.

4. During startup, the application creates temporary directories similar to:

   C:\Users\<user>\AppData\Local\OpenAI\Codex\bin\.staging-12219cbfbcbddde7-XXXXXX

5. The application attempts to rename the staging directory to:

   C:\Users\<user>\AppData\Local\OpenAI\Codex\bin\12219cbfbcbddde7

6. The rename fails with:

   • errno = -4048
   • code = EPERM
   • syscall = rename
   • operation = rename_staging

7. The final runtime directory is not created.

8. Runtime resolution then reports codex as missing.

9. App-server startup fails and the desktop application displays the generic error:

   Unable to locate the Codex CLI binary or required runtime components.

10. Re-launching the application repeats the process with newly generated .staging-* directories.

In one observed launch, several independent staging directories were created and failed within approximately five seconds, all targeting the same final hash directory.

Examples included staging suffixes such as:

• LpRRvs
• KLb0G0
• VZnKFb
• v86ipz
• dEu23b
• r1AO1T

All failed while trying to rename to:

...\bin\12219cbfbcbddde7

Relevant Logs

Representative log entries:

bundled_executable_relocation_failed

with fields equivalent to:

destinationPath=C:\Users\<user>\AppData\Local\OpenAI\Codex\bin\12219cbfbcbddde7

errorCode=EPERM

errorMessage="Bundled executable relocation failed during rename_staging"

executableName=codex.exe

operation=rename_staging

platform=win32

sourceKind=windowsapps

The underlying Windows error was:

errno=-4048

code=EPERM

syscall=rename

with a source similar to:

...\bin\.staging-12219cbfbcbddde7-XXXXXX

and destination:

...\bin\12219cbfbcbddde7

After the relocation failures, runtime resolution reported effectively:

component=codex
executablePath=null
source=missing

This was followed by an app-server transport connection failure and ultimately:

Desktop bootstrap failed to start the main app

The logs also contained:

Artifact Session host Unix-socket transport is not available on Windows.

However, this does not appear to be the cause, because bundled executable relocation continues after this warning and fails independently at rename_staging.

Diagnostics Already Performed

A substantial amount of troubleshooting was performed to eliminate common causes.

1. Clean reinstall

The application was completely uninstalled.

The following were verified before reinstalling:

• Get-AppxPackage OpenAI.Codex returned no installed package.
• %LOCALAPPDATA%\OpenAI\Codex was removed.
• The machine was rebooted.
• A fresh installation was performed.

The issue reproduced immediately after reinstall.

Therefore this does not appear to be caused by stale installation files.

2. Reproduced across different application versions

The same relocation behavior occurred on:

• 26.903.9818.0
• 26.908.9136.0

The runtime hash also changed between versions, but the same rename_staging -> EPERM failure remained.

Therefore this does not appear to be limited to one corrupted application package/version.

3. Runtime override environment variables checked

The following were checked at process/user/machine level and were not set:

• CODEX_CLI_PATH
• CODEX_HOME
• CODEX_NODE_PATH
• NODE_REPL_NODE_PATH

Therefore an explicit runtime override does not appear to be responsible.

4. Packaged codex.exe exists and is readable

The packaged codex.exe was confirmed to exist inside the WindowsApps package.

It could be copied manually to a temporary directory successfully.

The copied executable ran successfully and reported a valid Codex CLI version.

Therefore the bundled executable itself is present and readable.

5. Local directory ACL checked

The local Codex bin directory was inspected.

The current Windows user had FullControl, along with SYSTEM and Administrators.

A manually created directory inside the same bin directory could be renamed successfully.

Therefore this does not appear to be a static ACL problem on the destination directory.

6. Actual Codex-created staging directory can be manually renamed

This is an important observation.

After the failed application startup had exited, an actual .staging-* directory created by Codex was manually renamed using PowerShell.

The rename succeeded.

Therefore the Codex-created staging directory itself is not permanently unrenameable.

The failure appears to exist specifically while the application is running / during the bootstrap relocation sequence.

7. Destination collision checked

After a failed deployment:

C:\Users\<user>\AppData\Local\OpenAI\Codex\bin\12219cbfbcbddde7

did NOT exist.

Therefore the observed failures cannot simply be explained by the final target directory already existing at the time it was inspected after failure.

8. EFS/encryption checked

cipher /c showed that the packaged codex.exe was not EFS encrypted.

The executable could also be copied from the WindowsApps package successfully.

Therefore this does not appear to be the previously reported EFS/Application Protected copy failure class.

9. Windows long path support enabled

LongPathsEnabled was enabled and the machine was rebooted.

The problem persisted.

Therefore long-path support does not appear to be the cause.

10. CLI/configuration issues separately eliminated

Earlier configuration/CLI issues were identified and corrected, including an obsolete configuration value and stale runtime registrations.

A current Codex CLI executable could run independently.

The GUI bootstrap failure nevertheless remained.

Therefore these CLI configuration issues were not the cause of the desktop bootstrap relocation failure.

ProcMon Finding / Timing-Sensitive Behavior

This is the most interesting observation.

Because manual rename succeeded after the application exited, I started preparing Microsoft Sysinternals Process Monitor (ProcMon) to capture filesystem operations involving:

12219cbfbcbddde7

The intention was to capture the failed rename operation and determine whether another process or filesystem filter was temporarily holding the staging directory or executable.

During this diagnostic process, the application suddenly started successfully.

After this successful launch, the following final directory existed:

C:\Users\<user>\AppData\Local\OpenAI\Codex\bin\12219cbfbcbddde7

and it contained:

codex.exe

This was the final runtime state that had failed to be created during all previous launches.

No ACL changes, manual runtime copy, reinstall, or security-software configuration change was performed immediately before this successful relocation.

After the successful relocation, ChatGPT / Codex Desktop was completely closed and restarted three separate times.

All three subsequent launches succeeded.

Therefore the system went from:

repeated rename_staging -> EPERM

to:

successful staging -> hash-directory relocation

under effectively the same installation and filesystem permissions.

Once the hash runtime directory was successfully committed, subsequent launches became stable.

I cannot conclude that ProcMon itself "fixed" the problem.

However, the behavioral change while investigating with ProcMon is consistent with a timing-sensitive issue. ProcMon introduces additional filesystem instrumentation/latency and could potentially alter thread/process timing enough to make a race condition disappear.

This may be a Heisenbug-like symptom and may help reproduce/debug the issue.

Suspected Root Cause

The following is a hypothesis based on the observations above, not a confirmed root cause.

The evidence appears consistent with one of two closely related failure modes:

1. A race condition inside the Windows bundled-executable relocation/retry implementation.

2. A transient file/directory handle opened by another process or filesystem minifilter during the staging-to-final-directory rename.

The first possibility may be particularly worth investigating because logs showed several staging directories being created in rapid succession, all attempting relocation to the same final hash directory.

The application may therefore have multiple retry/relocation operations whose timing interacts poorly with Windows rename/share semantics.

Alternatively, a security scanner, EDR, Defender component, indexing service, backup/filter driver, or another process may temporarily open the newly created executable/directory in a way that prevents the atomic rename.

There is currently not enough evidence to attribute the problem to any specific third-party process or security product.

The important distinction is that the evidence does NOT look like a permanent filesystem permission failure:

• normal rename works in the same directory;
• an actual Codex-created staging directory can be renamed after application exit;
• the bundled executable can be read/copied;
• the destination does not persist after failed attempts;
• and eventually the exact relocation succeeds without changing ACLs.

Suggested Fix

It may be worth making the Windows bundled executable relocation code more tolerant of transient rename failures.

Possible improvements:

1. Treat Windows EPERM / sharing-related rename failures as potentially transient.

2. Retry the final rename with bounded exponential backoff and jitter rather than immediately creating multiple independent relocation attempts.

3. Ensure all file handles to files inside the staging directory are explicitly closed before attempting the directory rename.

4. Serialize relocation attempts for the same runtime hash so that only one staging directory can attempt to commit a given hash at a time.

5. Before retrying, detect whether another relocation attempt has already successfully created the target hash directory.

6. Where appropriate, distinguish:

   • access denied due to ACL,
   • sharing violation / open handle,
   • destination collision,
   • filesystem filter rejection,
     rather than mapping all cases to a generic EPERM relocation failure.

7. Add more Windows-specific diagnostic logging around the rename operation, including the native Win32 error code if available.

8. Consider a short Windows-specific retry window (for example hundreds of milliseconds to several seconds) before declaring the Codex runtime missing and aborting desktop bootstrap.

9. Avoid surfacing only:

   Unable to locate the Codex CLI binary

   when the CLI is actually present in the application package but its relocation failed.

   A more accurate error such as:

   Failed to deploy bundled Codex CLI: Windows could not rename the staging runtime directory (EPERM)

   would significantly improve troubleshooting.

Why I Believe This Is Worth Investigating

This failure can make the entire Windows desktop application unable to start even though:

• the application package is valid,
• codex.exe is present,
• the user has filesystem permission,
• the executable is readable,
• and the runtime can eventually deploy successfully without any permission change.

A transient Windows rename conflict should ideally not make the entire application permanently appear broken.

The fact that the application became stable immediately after one successful staging-to-hash relocation also strongly isolates the failure to the runtime deployment/commit path rather than general Codex execution.

I would be happy to provide additional logs or run a targeted ProcMon capture if the issue reproduces again after a future runtime/application update.

What steps can reproduce the bug?

fail to launch the software

What is the expected behavior?

No response

Additional information

No response

The payload names no source files or tests; begin with the Windows packaged-app startup path and logs for rename_staging and EPERM. Compare repeated staging attempts with the successful ProcMon-timed run, and define done as a stable runtime directory with subsequent launches succeeding without the missing-binary failure.