Skip to content

Codex Desktop for Windows crashes immediately after launch (26.527.3686.0) #25501

Closed

Description

@billwang2

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

Windows 11 24H2 (Build 26100.8457) Codex Desktop version: 26.527.3686.0 Installed from Microsoft Store ChatGPT Plus account

What subscription do you have?

Codex Desktop cannot be launched.

What platform is your computer?

No response

What issue are you seeing?

AppX container is successfully created.
Codex process is successfully created.
AppX container is immediately destroyed.
No window appears.
Crashpad generates a new .dmp file every launch.

Observed behavior:

AppModel Runtime logs show:
AppX container created successfully.
Codex process launched successfully.
AppX container destroyed immediately afterwards.
No Codex-related Application Error event is recorded.
New crash dump is generated on every launch:
Crashpad/reports/*.dmp

Troubleshooting already performed:

Reinstalled Codex multiple times.
Removed all local Codex data.
Removed Codex sandbox users.
Tested with a brand new Windows user account.
Enabled Hyper-V.
Enabled Containers.
Enabled HypervisorPlatform.
Verified vmcompute and hns services are running.
Ran SFC /scannow.
Ran DISM /RestoreHealth.
Disabled GPU acceleration using:
ELECTRON_DISABLE_GPU=1
LIBGL_ALWAYS_SOFTWARE=1
Disabled Microsoft Defender Controlled Folder Access.
Verified WebView2 is functioning.

Result:
The issue persists.

Crash dump location:
C:\Users\AppData\Local\Packages\OpenAI.Codex_*\LocalCache\Roaming\Codex\web\Codex\Crashpad\reports

Latest dump:
b7b56248-2e35-4824-9b6a-152118960d73.dmp

Expected behavior:
Codex Desktop should open normally.

Actual behavior:
The process exits immediately and a crash dump is generated.

What steps can reproduce the bug?

AppX container is successfully created.
Codex process is successfully created.
AppX container is immediately destroyed.
No window appears.
Crashpad generates a new .dmp file every launch.

Observed behavior:

AppModel Runtime logs show:
AppX container created successfully.
Codex process launched successfully.
AppX container destroyed immediately afterwards.
No Codex-related Application Error event is recorded.
New crash dump is generated on every launch:
Crashpad/reports/*.dmp

Troubleshooting already performed:

Reinstalled Codex multiple times.
Removed all local Codex data.
Removed Codex sandbox users.
Tested with a brand new Windows user account.
Enabled Hyper-V.
Enabled Containers.
Enabled HypervisorPlatform.
Verified vmcompute and hns services are running.
Ran SFC /scannow.
Ran DISM /RestoreHealth.
Disabled GPU acceleration using:
ELECTRON_DISABLE_GPU=1
LIBGL_ALWAYS_SOFTWARE=1
Disabled Microsoft Defender Controlled Folder Access.
Verified WebView2 is functioning.

Result:
The issue persists.

Crash dump location:
C:\Users\AppData\Local\Packages\OpenAI.Codex_*\LocalCache\Roaming\Codex\web\Codex\Crashpad\reports

Latest dump:
b7b56248-2e35-4824-9b6a-152118960d73.dmp

Expected behavior:
Codex Desktop should open normally.

Actual behavior:
The process exits immediately and a crash dump is generated.

What is the expected behavior?

No response

Additional information

No response

Activity

  1. added
    appIssues related to the Codex desktop app
    on Jun 1, 2026
  2. added
    bugSomething isn't working
    windows-osIssues related to Codex on Windows systems
    on Jun 1, 2026
  3. github-actions commented on Jun 1, 2026

    @github-actions
    Contributor
  4. billwang2 commented on Jun 2, 2026

    @billwang2
    Author

    Update:

    I tested Codex-win-x64-26.519.81530 on the same machine.

    26.519.81530 launches successfully.

    OpenAI.Codex_26.527.3686.0 crashes immediately on startup and generates Crashpad dumps.

    Same Windows installation.
    Same user account.
    Same hardware.

    This appears to be a regression introduced between 26.519 and 26.527.

  5. shaneintheuk commented on Jun 2, 2026

    @shaneintheuk

    I am seeing the same failure.

    My current Store version is:

    OpenAI.Codex_26.527.7698.0_x64__2p2nqsd0c76g0

    Originally the issue started immediately after an in-app update. The app said it would restart, but never came back. Since then:

    • AppX package repair succeeds
    • AppX activation succeeds
    • Codex process is created
    • AppX container is immediately destroyed
    • No Codex Application Error appears in Windows Application logs
    • Crashpad generates a new .dmp on every launch

    Crash dump path:

    %LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Roaming\Codex\web\Codex\Crashpad\reports

    I also tried:

    • Repair
    • Reset
    • Uninstall/reinstall
    • Renaming C:\Users<user profile>.codex
    • Renaming C:\Users<user profile>\AppData\Local\OpenAI\Codex

    No change.

    After updating from the Microsoft Store today, I am now on 26.527.7698.0 and the issue still persists.

    Given the comment above that 26.519.81530 launches successfully on the same machine, this looks like a regression in the 26.527 Windows desktop builds.

  6. TinyFatty commented on Jun 2, 2026

    @TinyFatty

    I was able to work around this by downgrading to an older MSIX package.
    For anyone really urgent to use, here is the old version link.Just choose any version before 527 and manually install.
    Old Version Codex

    My findings

    Affected Store versions on my machine

    • OpenAI.Codex 26.527.7698.0
    • Codex Beta also reproduced the same crash.

    Behavior

    • The app launches a process, but no UI appears.
    • Crashpad generates a dump on each launch.
    • WinDbg consistently reports the same crash:
    PROCESS_NAME: Codex.exe
    EXCEPTION_CODE: 0xc0000005
    Failure.Bucket: INVALID_POINTER_READ_c0000005_chrome.dll!Unknown
    MODULE_NAME: chrome
    IMAGE_NAME: chrome.dll
    IMAGE_VERSION: 148.0.7778.179
    Faulting symbol: chrome!v8::Context::Exit+0x1b
    Failure hash: {5cd13162-58f6-4190-dced-e6b658b0f99b}
    

    Beta build

    The Beta build crashed at the same place as well:

    PROCESS_NAME: Codex (Beta).exe
    Failure.Bucket: INVALID_POINTER_READ_c0000005_chrome.dll!Unknown
    MODULE_NAME: chrome
    IMAGE_NAME: chrome.dll
    IMAGE_VERSION: 148.0.7778.179
    Faulting symbol: chrome!v8::Context::Exit+0x1b
    Failure hash: {5cd13162-58f6-4190-dced-e6b658b0f99b}
    

    Things I tried that did not help

    • Uninstalling and reinstalling Codex from Microsoft Store
    • Installing the Beta version
    • Rebooting Windows
    • Resetting / clearing Codex local app data
    • Creating a new Windows local user
    • Clean boot: disabling all non-Microsoft services and almost all startup items
    • Disabling Intel UHD Graphics 770
    • Minimal PATH environment
    • --no-sandbox, --disable-gpu, --disable-gpu-sandbox, and related Chromium flags
    • Checking Exploit Protection / process mitigation settings
    • Checking AppInit_DLLs, IFEO, and AppCompatFlags
    • Checking loaded modules in WinDbg; I did not see obvious third-party DLL injection
    • Checking file-system filter drivers; nothing obvious explained the crash
    • Running:
    DISM /Online /Cleanup-Image /RestoreHealth

    Interesting comparison

    The new Codex version works fine on another PC at my home with the same Windows version and same hardware.

  7. peikgabriel commented on Jun 3, 2026

    @peikgabriel

    Same failure. It's laggy, freezes almost instantly after launching the app. Entirely unusable at the current state.

  8. wvdweij commented on Jun 3, 2026

    @wvdweij

    Same problem here, Codex-Cli narrowed it down to chrome.dll, tried all the things to that TS did

  9. leiyan commented on Jun 6, 2026

    @leiyan

    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.

  10. billwang2 commented on Jun 7, 2026

    @billwang2
    Author

    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.

    Update: I found the root cause and a workaround.

    Codex Desktop was crashing immediately after launch because my Windows machine had a machine-level environment variable set:

    NODE_OPTIONS=--openssl-legacy-provider
    It was stored under:
    
    HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment
    After deleting this machine-level NODE_OPTIONS value, Codex Desktop was able to upgrade and launch normally.
    
    I removed it with an elevated/admin PowerShell or terminal:
    
    reg delete "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment" /v NODE_OPTIONS /f
    Then I verified it was gone:
    
    [Environment]::GetEnvironmentVariable("NODE_OPTIONS", "Machine")
    This should return empty/null.
    
    For context, I originally had --openssl-legacy-provider set because an older Vue/Webpack project needed it. That global setting affected Codex Desktop as well.
    
    A safer workaround is to keep the flag only at the specific old frontend project level, for example in that project’s .npmrc:
    
    node-options=--openssl-legacy-provider
    This lets the old Webpack project keep working without setting NODE_OPTIONS globally for every Node/Electron-based app.
    
    So the issue appears to be triggered by Codex Desktop inheriting a machine-level NODE_OPTIONS=--openssl-legacy-provider.
    
    Suggestion: Codex Desktop could ignore/sanitize inherited NODE_OPTIONS, or show a clearer startup error when this environment variable causes the app runtime to fail.
    
  11. wvdweij commented on Jun 7, 2026

    @wvdweij

    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.

    Update: I found the root cause and a workaround.

    Codex Desktop was crashing immediately after launch because my Windows machine had a machine-level environment variable set:

    NODE_OPTIONS=--openssl-legacy-provider
    It was stored under:
    
    HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment
    After deleting this machine-level NODE_OPTIONS value, Codex Desktop was able to upgrade and launch normally.
    
    I removed it with an elevated/admin PowerShell or terminal:
    
    reg delete "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment" /v NODE_OPTIONS /f
    Then I verified it was gone:
    
    [Environment]::GetEnvironmentVariable("NODE_OPTIONS", "Machine")
    This should return empty/null.
    
    For context, I originally had --openssl-legacy-provider set because an older Vue/Webpack project needed it. That global setting affected Codex Desktop as well.
    
    A safer workaround is to keep the flag only at the specific old frontend project level, for example in that project’s .npmrc:
    
    node-options=--openssl-legacy-provider
    This lets the old Webpack project keep working without setting NODE_OPTIONS globally for every Node/Electron-based app.
    
    So the issue appears to be triggered by Codex Desktop inheriting a machine-level NODE_OPTIONS=--openssl-legacy-provider.
    
    Suggestion: Codex Desktop could ignore/sanitize inherited NODE_OPTIONS, or show a clearer startup error when this environment variable causes the app runtime to fail.
    

    Thank you! Solved!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions