codex - 💡(How to fix) Fix Windows Desktop 26.527.3686.0 AppsFolder launch opens Chrome and exits; direct Codex.exe launch works

Summary

On Windows, launching Codex Desktop through the normal packaged app activation path (shell:AppsFolder\OpenAI.Codex_2p2nqsd0c76g0!App, e.g. Start menu / original desktop shortcut) unexpectedly opens Chrome and the Codex Desktop window does not start or stay running.

Launching the packaged executable directly from the MSIX install directory with Electron logging flags does start the app successfully.

Environment

• Codex Desktop package: OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0
• Codex Desktop version: 26.527.3686.0
• Install location: C:\Program Files\WindowsApps\OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0
• OS: Windows 11 Pro for Workstations, version 10.0.22000, build 22000
• Codex CLI also installed separately: codex-cli 0.130.0

Steps to reproduce

1. Launch Codex Desktop using the normal packaged app entry point:
   • Start menu entry, or
   • a shortcut targeting explorer.exe shell:AppsFolder\OpenAI.Codex_2p2nqsd0c76g0!App
2. Observe that Chrome opens unexpectedly.
3. Observe that the Codex Desktop app does not visibly start / does not remain running.
4. Launch the packaged executable directly instead:

$app = 'C:\Program Files\WindowsApps\OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0\app'
Start-Process -FilePath "$app\Codex.exe" -WorkingDirectory $app -ArgumentList '--enable-logging=stderr','--v=1'

1. Observe that Codex Desktop launches successfully and the main window reaches ready-to-show.

Expected behavior

The Start menu / AppsFolder activation path should launch Codex Desktop directly and reliably, without opening Chrome unexpectedly or exiting before the main window is usable.

Actual behavior

The packaged app activation path opens Chrome and Codex Desktop does not become usable. A direct Codex.exe launch with --enable-logging=stderr --v=1 works as a workaround.

Workarounds tried

• Reset-AppxPackage -Package OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0
• Re-registering the package manifest with Add-AppxPackage -DisableDevelopmentMode -Register ...\AppxManifest.xml
• Removing stale .staging-* directories under %LOCALAPPDATA%\OpenAI\Codex\bin
• Replacing the desktop shortcut with a wrapper that resolves the current AppX package and directly starts Codex.exe with --enable-logging=stderr --v=1

The wrapper workaround is currently usable, but the native AppsFolder / Start menu entry remains unreliable.

Relevant logs

The direct/package launch that succeeds still reports repeated EPERM staging/rename failures:

2026-05-30T04:55:12.522Z info Launching app packaged=true platform=win32
2026-05-30T04:55:13.242Z warning bundled_executable_relocation_failed destinationPath=%LOCALAPPDATA%\OpenAI\Codex\bin\7dea4a003bc76627 errorCode=EPERM errorMessage="Bundled executable relocation failed during rename_staging" errorName=BundledExecutableRelocationError executableName=codex.exe failedExecutableName=codex.exe operation=rename_staging originalError={"errno":-4048,"code":"EPERM","syscall":"rename","path":"%LOCALAPPDATA%\\OpenAI\\Codex\\bin\\.staging-7dea4a003bc76627-...","dest":"%LOCALAPPDATA%\\OpenAI\\Codex\\bin\\7dea4a003bc76627"} platform=win32 sourceKind=windowsapps
2026-05-30T04:55:14.055Z info [window-manager] window ready-to-show appearance=primary hostId=local startupElapsedMs=108 webContentsId=1 windowId=1
2026-05-30T04:55:23.616Z warning [BundledPluginsMarketplace] bundled_plugins_marketplace_resolve_failed errorCode=EPERM errorMessage="EPERM: operation not permitted, rename '%USERPROFILE%\\.codex\\.tmp\\bundled-marketplaces\\openai-bundled.staging-...' -> '%USERPROFILE%\\.codex\\.tmp\\bundled-marketplaces\\openai-bundled'"

There is also a separate warning during first-turn/project startup:

Primary runtime install failed before first turn errorMessage="Codex Workspace dependencies are not supported on Windows 10."

That appears separate from the app launch failure, but it may be relevant because this machine is Windows 11 build 22000 while the runtime installer reports the Windows 10 unsupported path.

Notes

This started after the Desktop package changed to 26.527.3686.0; older local logs show prior 26.506.*, 26.513.*, and 26.519.* package generations. I could not find an existing issue matching BundledExecutableRelocationError / rename_staging exactly.