Windows Desktop 26.527.3686.0 AppsFolder launch opens Chrome and exits; direct Codex.exe launch works

Open 💬 8 comments Opened May 30, 2026 by mfushun-cmyk
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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
  1. Observe that Chrome opens unexpectedly.
  2. Observe that the Codex Desktop app does not visibly start / does not remain running.
  3. 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.

View original on GitHub ↗

8 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #25197
  • #25001

Powered by Codex Action

mfushun-cmyk · 1 month ago

Update after reinstall:

I uninstalled/reinstalled Codex Desktop and the issue still reproduces with the native Start menu / AppsFolder activation path.

Current package after reinstall is still:

OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0
version 26.527.3686.0

After reinstall, the desktop workaround shortcut was removed/cleared, so I recreated it to directly launch:

Codex.exe --enable-logging=stderr --v=1

That workaround continues to work: launching the recreated desktop shortcut starts Codex Desktop, the app process stays running, and no new Chrome process is created. The native AppsFolder / Start menu entry remains the problematic path.

mfushun-cmyk · 1 month ago

Additional plugin regression after reinstall / workaround details:

After reinstalling Codex Desktop 26.527.3686.0, the app could be launched via the direct shortcut workaround, but bundled plugins that previously worked were unavailable or broken, specifically Chrome and Computer Use.

Observed broken state:

  • codex plugin marketplace list did not include openai-bundled; only openai-curated / another marketplace were visible.
  • ~/.codex/config.toml still had [plugins."chrome@openai-bundled"], [plugins."computer-use@openai-bundled"], and [plugins."browser@openai-bundled"] enabled, but the configured openai-bundled source had previously pointed at a transient path under ~/.codex/.tmp/bundled-marketplaces/openai-bundled, which was missing.
  • Desktop log before repair showed:
computer-use notify config ensure finished platform=win32 reason=missing-helper-path status=skipped
computer-use native pipe startup failed errorMessage="Windows Computer Use helper paths are unavailable"
BundledPluginsMarketplace ... pluginCount=1 pluginNames=["latex"]

Repair that restored Browser / Chrome / Computer Use visibility:

codex plugin marketplace add "C:\Program Files\WindowsApps\OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0\app\resources\plugins\openai-bundled"

After that:

browser@openai-bundled       installed, enabled  26.527.31326
chrome@openai-bundled        installed, enabled  0.1.7
computer-use@openai-bundled  installed, enabled  26.527.31326

And after restarting Desktop:

computer-use native pipe startup ready ... platform=win32
BundledPluginsMarketplace ... pluginCount=4 pluginNames=["browser","chrome","computer-use","latex"]

Chrome-specific issue after reinstall:

  • Registry key existed: HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension
  • But it pointed to a missing manifest: %LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json
  • The packaged installManifest.mjs attempted to write extension-host-config.json next to extension-host.exe inside C:\Program Files\WindowsApps\..., which failed with EPERM because the MSIX package directory is read-only.

Workaround used:

  • Copy the packaged Chrome extension-host.exe to %LOCALAPPDATA%\OpenAI\extension\extension-host.exe
  • Write %LOCALAPPDATA%\OpenAI\extension\extension-host-config.json next to it with the runtime paths
  • Write %LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json pointing to that copied host
  • Ensure the registry default value points to that manifest

Validation after repair:

check-native-host-manifest.js --json -> correct: true
check-extension-installed.js --json -> installed: true, enabled: true

This machine also has Chrome user data under a non-default path:

C:\Users\Administrator\AppData\Roaming\Microsoft\Google\Chrome\User Data

Setting CODEX_CHROME_USER_DATA_DIR to that path was required for the bundled Chrome checks to detect the installed extension.

DennisdeJager · 1 month ago

Additional reproduction data from another Windows machine on the same Desktop package:

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 build: 10.0.26200
GPU: NVIDIA GeForce RTX 3080, driver 32.0.16.1047 / 2026-05-19
Global Codex CLI: 0.135.0

Observed behavior:

  • Launching through normal packaged activation (explorer.exe shell:AppsFolder\OpenAI.Codex_2p2nqsd0c76g0!App) creates the AppX container and process, then exits almost immediately.
  • Direct launch from the MSIX install directory with the app working directory also exits immediately on this machine:
$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'

Crashpad evidence is consistent across multiple attempts. All minidumps report the same exception:

Exception: EXCEPTION_ACCESS_VIOLATION / 0xc0000005
Exception information: [0x0, 0x1f0]
Faulting module: C:\Program Files\WindowsApps\OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0\app\chrome.dll
Fault offset: 0x496963b
Process product/version in dump: Codex / 148.0.7778.179
Process type: browser

Examples from the local Crashpad reports:

c59d167b-9a32-483a-a3aa-a7e8a6d638a4.dmp  code 0xc0000005  chrome.dll offset 0x496963b
3cfbc844-b851-4177-87f3-550827b795b0.dmp  code 0xc0000005  chrome.dll offset 0x496963b
63970fa6-eef0-4668-8cf0-7822608a8e38.dmp  code 0xc0000005  chrome.dll offset 0x496963b
f5ebbcc0-e94d-49e8-8be5-4f2c3a427dec.dmp  code 0xc0000005  chrome.dll offset 0x496963b
30079223-2768-4737-a005-bb732c66660c.dmp  code 0xc0000005  chrome.dll offset 0x496963b

Workarounds tried on this machine:

  • --disable-gpu --disable-software-rasterizer --no-first-run: still crashes, same chrome.dll offset.
  • Temporarily moved %LOCALAPPDATA%\OpenAI\Codex\bin aside to rule out stale local backend binaries: still crashes before recreating the bin cache.
  • Verified package status with Get-AppxPackage -Name OpenAI.Codex: Status: Ok, SignatureKind: Store.

This looks like a native Chromium/Electron browser-process crash in the 26.527.3686.0 Windows package rather than a workspace, MCP, sandbox, or CLI configuration issue.

leiyan · 1 month ago

You can check whether your system has this environment variable set:
NODE_OPTIONS=--openssl-legacy-provider
If it exists, try deleting it and then see if Codex launches normally.

DennisdeJager · 1 month ago
You can check whether your system has this environment variable set: NODE_OPTIONS=--openssl-legacy-provider If it exists, try deleting it and then see if Codex launches normally.

Hi, I had this one: NODE_OPTIONS --experimental-default-type=commonjs
After removing it codex started working again, finally after a week!

Thanks!

Oyvindwpetersen · 1 month ago

Making a shortcut to
_"C:\Program Files\WindowsApps\OpenAI.Codex_26.602.4764.0_x64__2p2nqsd0c76g0\app\Codex.exe" --enable-logging=stderr --v=1_
worked for me, but Codex is still very unstable and constantly freezing

mikepfleetcor-del · 1 month ago

Making the shortcut worked for me as well "--enable-logging=stderr --v=1". I installed Codex and Codex Beta and same issue for both. Shortcut worked for both. However the logging window gets stuck at times and I have to Enter to continue the process. Not to mention it is extremely slower than before. Stopped working 1 week ago. I am using version OpenAI.Codex_26.609.4994.0_x64 and OpenAI.CodexBeta_26.527.7698.0_x64

Original Issue - Clicking on the App Shortcut/Links takes me straight to Chrome (home page) on Codex and Codex Beta, after two uninstallation s and 2 Window repairs.