[Windows] Startup fails after a Store update with rename_staging EPERM for CLI and Node runtime

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

26.908.9136.0

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Windows 11 Pro 24H2, OS build 26100.4652, x64.

What issue are you seeing?

After a Microsoft Store update, the desktop app repeatedly failed to start with:

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

The startup logs show bundled_executable_relocation_failed with operation=rename_staging and errorCode=EPERM for both codex.exe and the bundled cua_node runtime (node.exe and node_repl.exe). The underlying error has errno=-4048 and syscall=rename, with a .staging-* directory as the source and a hash-named cache directory as the destination.

On September 15, 2026, I recorded the following launches. Times in this table are UTC+8:

Launch started	Result
11:15:11	Bootstrap failed at 11:15:35
11:16:05	Bootstrap failed at 11:16:27
11:25:51	Bootstrap failed at 11:26:11
11:31:26	CLI initialized at 11:31:52; the app became usable

These are selected fields from the failed 11:15 launch, with paths redacted and stack traces omitted. Log timestamps are UTC:

2026-09-15T03:15:19.758Z warning bundled_executable_relocation_failed
executableName=codex.exe
operation=rename_staging
errorCode=EPERM
originalError={"errno":-4048,"code":"EPERM","syscall":"rename","path":"%LOCALAPPDATA%\\OpenAI\\Codex\\bin\\.staging-12219cbfbcbddde7-lGUQC4","dest":"%LOCALAPPDATA%\\OpenAI\\Codex\\bin\\12219cbfbcbddde7"}

2026-09-15T03:15:26.835Z warning bundled_executable_relocation_failed
executableName=node_repl.exe
operation=rename_staging
errorCode=EPERM
destinationPath=%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\6f12e0ef1c6e5061

2026-09-15T03:15:35.304Z error Desktop bootstrap failed to start the main app phase=bootstrap-import-main

The later successful launch still logged relocation failures:

• At 11:31:48.286, codex.exe relocation failed with rename_staging / EPERM.
• At 11:31:48.940, the resolver found codex.exe in the final cache directory and recorded source=copied.
• At 11:31:52.311, node.exe relocation still failed. At 11:31:52.319, rg.exe relocation also failed with the same operation and error code.
• At 11:31:52.731, the log recorded Codex CLI initialized.
• At 11:32:04.375, both node.exe and node_repl.exe resolved from the final cua_node directory with source=copied.

What steps can reproduce the bug?

The sequence I observed was:

1. Update the Windows desktop app through Microsoft Store.
2. Launch the app.
3. The startup error appears. Relaunching produced the same error on three recorded attempts.
4. A later launch succeeded, with the partial recovery sequence above.

What is the expected behavior?

The app should prepare its bundled runtime and start normally after a Store update. If preparation fails, the error should identify the failed operation and cache path so the startup problem can be diagnosed.

Additional information

The cached CLI currently runs and reports codex-cli 0.154.0-alpha.6.2.

During troubleshooting, I restored a missing rg.exe under %LOCALAPPDATA%\OpenAI\Codex\bin\4fe45441001f7a41\ and removed the leftover .staging-4fe45441001f7a41-r6CmnT directory. The restored rg.exe has a creation time of 11:34:06, after the successful CLI initialization, so that restoration does not explain the earlier recovery.

I also set the user-level CODEX_CLI_PATH variable to the cached %LOCALAPPDATA%\OpenAI\Codex\bin\12219cbfbcbddde7\codex.exe. I have not isolated the effect of this override or verified what happens after another Store update.

Start at the Desktop bootstrap, bundled executable relocation, and resolver paths described in the logs, focusing on rename_staging failures with EPERM after a Store update. Reproduce the update-and-launch sequence on Windows and trace the codex.exe and bundled runtime handling; done means startup succeeds reliably or reports an actionable failure with the relevant cache path.