Skip to content

Codex randomly crashes #24598

Open
Open

Description

@Hal9000AIML

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

26.519.41501

What subscription do you have?

Pro

What platform is your computer?

Windows 11

What issue are you seeing?

Codex App randomly crashes completely.

What steps can reproduce the bug?

Run Codex. Wait a few minutes. It crashes.

What is the expected behavior?

No response

Additional information

No response

Activity

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

    @github-actions
    Contributor

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

    Powered by Codex Action

  4. etraut-openai commented on May 26, 2026

    @etraut-openai
    Contributor

    Thanks for the bug report, but there's not enough detail here for us to investigate. If you're able to provide more information, let us know.

  5. Hal9000AIML commented on May 26, 2026

    @Hal9000AIML
    Author

    Codex Desktop Crash and Stability Report - Redacted

    Generated: 2026-05-26
    Platform: Windows
    User/path redaction: local username and home-directory paths replaced with <USER> / %USERPROFILE%

    Privacy Notes

    This version is safer to paste into a support ticket or public issue. I redacted:

    • Windows username.
    • Full user-profile paths.
    • Long local binary/cache hashes.
    • Exact Windows Error Reporting report IDs and hashed buckets.
    • Exact WER archive folder names.

    Do not publicly upload raw Codex SQLite logs or session files unless you are comfortable sharing prompts, local paths, command history, project names, and tool output. For OpenAI private support, attach raw logs only if they explicitly ask for them.

    Environment

    OS: Windows
    Codex package observed: OpenAI.Codex_26.519.5221.0_x64__<PACKAGE_SUFFIX_REDACTED>
    Codex desktop app version in Windows event log: 3044.0.0.0
    Codex app client version seen in logs: 26.519.41501
    Codex CLI/runtime binary observed: %LOCALAPPDATA%\OpenAI\Codex\bin\<HASH_REDACTED>\codex.exe
    

    Executive Summary

    I found one Windows-recorded Codex Desktop application hang, plus a much larger volume of Python native crashes occurring during the same general period.

    The Codex-specific hang was:

    Time: 2026-05-25 6:51:15 PM America/New_York
    Provider: Application Hang
    Event ID: 1002
    Program: Codex.exe
    Version: 3044.0.0.0
    Message: The program Codex.exe version 3044.0.0.0 stopped interacting with Windows and was closed.
    

    Windows Error Reporting recorded the matching app hang:

    Time: 2026-05-25 6:51:16 PM America/New_York
    Provider: Windows Error Reporting
    Event ID: 1001
    Event Name: MoAppHang
    P1: OpenAI.Codex_26.519.5221.0_x64__<PACKAGE_SUFFIX_REDACTED>
    P2: praid:App
    P3: 3044.0.0.0
    Report Id: <WER_REPORT_ID_REDACTED>
    Hashed bucket: <HASHED_BUCKET_REDACTED>
    WER archive path: C:\ProgramData\Microsoft\Windows\WER\ReportArchive\Critical_OpenAI.Codex_26._<REDACTED>
    

    The WER archive folder exists, but reading its contents from the diagnostic session returned:

    Access to the path ... is denied.
    

    So the event-log summary is available, but the hang dump/report contents were not readable without elevated Windows access.

    High-Volume Native Crashes

    In the last 24 hours, Windows Application logs showed:

    Windows Error Reporting, Event ID 1001: 357 matching events
    Application Error, Event ID 1000:      353 matching events
    Application Hang, Event ID 1002:         1 matching event
    

    Grouped by fault signature:

    python.exe / hnswlib / 0xc0000005          468 events
    pythonw.exe / python311.dll / 0xc00000fd   230 events
    Codex/OpenAI app hang                        2 WER/Application Hang records for the same hang
    

    Representative hnswlib access violation:

    Time: 2026-05-26 11:46:53 AM America/New_York
    Provider: Application Error
    Event ID: 1000
    Faulting application name: python.exe
    Faulting application version: 3.11.9150.1013
    Faulting module name: hnswlib.cp311-win_amd64.pyd
    Exception code: 0xc0000005
    Fault offset: 0x00000000000246f4
    Faulting process id: <PID_REDACTED>
    Faulting application path: C:\Program Files\Python311\python.exe
    Faulting module path: C:\Program Files\Python311\Lib\site-packages\hnswlib.cp311-win_amd64.pyd
    Report Id: <WER_REPORT_ID_REDACTED>
    

    Representative pythonw.exe stack overflow:

    Time: 2026-05-26 11:46:23 AM America/New_York
    Provider: Application Error
    Event ID: 1000
    Faulting application name: pythonw.exe
    Faulting application version: 3.11.9150.1013
    Faulting module name: python311.dll
    Exception code: 0xc00000fd
    Faulting application path: C:\Program Files\Python311\pythonw.exe
    Faulting module path: C:\Program Files\Python311\python311.dll
    Report Id: <WER_REPORT_ID_REDACTED>
    

    0xc0000005 is an access violation. 0xc00000fd is a stack overflow.

    Python Package Finding

    The crashing hnswlib.cp311-win_amd64.pyd was associated with chroma-hnswlib, not a standalone hnswlib Python package.

    Before remediation:

    Python executable: C:\Program Files\Python311\python.exe
    Python version: 3.11.9
    chroma-hnswlib: 0.7.6
    hnswlib metadata: PackageNotFoundError for package name hnswlib
    hnswlib module origin: C:\Program Files\Python311\Lib\site-packages\hnswlib.cp311-win_amd64.pyd
    chroma-hnswlib dist-info: C:\Program Files\Python311\Lib\site-packages\chroma_hnswlib-0.7.6.dist-info
    

    Package index check:

    chroma-hnswlib available versions: 0.7.6, 0.7.5, 0.7.3, 0.7.2, 0.7.1, 0.7.0
    Installed: 0.7.6
    Latest: 0.7.6
    

    No newer package version was available.

    Remediation Applied Locally

    1. Disabled an invalid Codex plugin entry.

    Codex config had:

    [plugins."chrome@openai-bundled"]
    enabled = true

    The cache path existed:

    %USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome\26.519.41501
    

    But it did not contain:

    .codex-plugin\plugin.json
    

    Codex logs repeatedly emitted:

    failed to load plugin: missing or invalid plugin.json plugin="chrome@openai-bundled"
    

    Local change applied:

    [plugins."chrome@openai-bundled"]
    enabled = false

    The valid browser plugin remains enabled:

    [plugins."browser@openai-bundled"]
    enabled = true
    1. Installed a clean user-level copy of chroma-hnswlib without changing dependencies.

    Command run:

    python.exe -m pip install --user --force-reinstall --no-deps chroma-hnswlib==0.7.6

    Result:

    Successfully installed chroma-hnswlib-0.7.6
    

    After remediation:

    hnswlib origin: %APPDATA%\Python\Python311\site-packages\hnswlib.cp311-win_amd64.pyd
    

    Smoke test:

    Created hnswlib Index(space='l2', dim=4)
    Initialized index
    Added 5 vectors
    Ran knn_query(k=2)
    Result: hnswlib smoke test ok
    

    This should cause normal user Python runs to load the user-profile copy instead of the system-wide Program Files copy.

    Codex Sandbox / Workspace Problem

    Codex was being run from C:\ in the diagnostic session. The config also marked c:\ as trusted:

    [projects.'c:\']
    trust_level = "trusted"

    Codex sandbox setup fails when trying to grant write access at the drive root:

    2026-05-26 11:03:14
    granting write ACE to C:\ for sandbox group and capability SID
    write ACE grant failed on C:\: SetNamedSecurityInfoW failed: 5
    setup refresh completed with errors: ["write ACE failed on C:\\: SetNamedSecurityInfoW failed: 5"]
    setup error: setup refresh had errors
    

    The same issue occurred again:

    2026-05-26 11:04:20
    write ACE grant failed on C:\: SetNamedSecurityInfoW failed: 5
    setup error: setup refresh had errors
    

    Codex SQLite logs then surface related execution failures:

    windows sandbox: runner error: CreateProcessAsUserW failed: 5
    

    Last 36 hours Codex ERROR summary:

    CreateProcessAsUserW failed: 5   56
    blocked by policy                20
    remote host closed connection     1
    other                            53
    

    Recommendation: do not use C:\ as a Codex workspace. Use a normal project directory such as:

    C:\Code\<project-name>
    %USERPROFILE%\<project-name>
    

    The drive root ACL failure is local/environmental and is distinct from the Codex Desktop MoAppHang.

    Other Codex Log Warnings

    Codex log locations, redacted:

    %USERPROFILE%\.codex\logs_2.sqlite
    %USERPROFILE%\.codex\log\codex-tui.log
    %USERPROFILE%\.codex\.sandbox\sandbox.log
    

    Recent warnings in logs_2.sqlite over the last 36 hours:

    ignored icon metadata:        2693
    missing plugin json:           124
    shell snapshot unsupported:    105
    Cloudflare/403 app list:         1
    tool suggestions failed:         1
    other:                         250
    

    Examples:

    failed to load plugin: missing or invalid plugin.json plugin="chrome@openai-bundled"
    
    Failed to create shell snapshot for powershell: Shell snapshot not supported yet for PowerShell
    
    failed to load discoverable tool suggestions: request failed with status 403 Forbidden
    

    The PowerShell shell snapshot warning appears informational. The invalid Chrome plugin warning was locally addressed by disabling the invalid plugin entry.

    Current Assessment

    What was likely local and addressed:

    • Repeated invalid plugin warnings from chrome@openai-bundled were addressed by disabling that stale/invalid plugin entry.
    • Python native crashes involving C:\Program Files\Python311\Lib\site-packages\hnswlib.cp311-win_amd64.pyd were mitigated by installing a user-level copy of chroma-hnswlib==0.7.6, which now takes precedence in Python imports.

    What remains environmental:

    • Codex sandbox command execution can fail when the workspace is C:\ because Codex tries to grant ACLs at the drive root and receives Windows access denied (SetNamedSecurityInfoW failed: 5). Use a non-root workspace directory.

    What remains for OpenAI if it recurs:

    • The Codex Desktop MoAppHang on 2026-05-25 6:51 PM EDT should be investigated if it happens again, especially if hangs continue after:
      • avoiding C:\ as the workspace;
      • disabling the invalid Chrome plugin entry;
      • mitigating the Python hnswlib native crash.

    Suggested OpenAI Support Summary

    Codex Desktop on Windows hung and was closed by Windows on 2026-05-25 at 6:51 PM EDT. Windows logged Application Hang Event ID 1002 for Codex.exe version 3044.0.0.0, with WER Event ID 1001 MoAppHang for package OpenAI.Codex_26.519.5221.0_x64__<PACKAGE_SUFFIX_REDACTED>.

    Local diagnostics also found a stale enabled plugin entry chrome@openai-bundled whose cache did not contain .codex-plugin\plugin.json, producing repeated missing or invalid plugin.json warnings. That entry was disabled while keeping browser@openai-bundled enabled.

    There are also sandbox failures when the workspace is rooted at C:\: write ACE failed on C:\: SetNamedSecurityInfoW failed: 5, later surfacing as windows sandbox: runner error: CreateProcessAsUserW failed: 5. The user should avoid C:\ as a workspace.

    Separately, Windows logged hundreds of native Python crashes involving python.exe and pythonw.exe, especially hnswlib.cp311-win_amd64.pyd access violations (0xc0000005) and python311.dll stack overflows (0xc00000fd). A clean user-level chroma-hnswlib==0.7.6 install was applied so Python now imports hnswlib from the user profile rather than C:\Program Files\Python311\Lib\site-packages.

    Files to Reference Privately

    If submitting a private OpenAI support ticket, reference these locations after replacing placeholders with local paths as needed:

    %USERPROFILE%\.codex\logs_2.sqlite
    %USERPROFILE%\.codex\log\codex-tui.log
    %USERPROFILE%\.codex\.sandbox\sandbox.log
    %USERPROFILE%\.codex\config.toml
    Windows Event Viewer > Windows Logs > Application
    

    Do not publicly attach the raw files above. They may contain command history, prompts, local project paths, and other sensitive context.

    The WER archive folder exists but may require Administrator access to read:

    C:\ProgramData\Microsoft\Windows\WER\ReportArchive\Critical_OpenAI.Codex_26._<REDACTED>
    
  6. Hal9000AIML commented on May 26, 2026

    @Hal9000AIML
    Author

    Codex Desktop Crash and Stability Report - Redacted

    Generated: 2026-05-26
    Platform: Windows
    User/path redaction: local username and home-directory paths replaced with <USER> / %USERPROFILE%

    Privacy Notes

    This version is safer to paste into a support ticket or public issue. I redacted:

    • Windows username.
    • Full user-profile paths.
    • Long local binary/cache hashes.
    • Exact Windows Error Reporting report IDs and hashed buckets.
    • Exact WER archive folder names.

    Do not publicly upload raw Codex SQLite logs or session files unless you are comfortable sharing prompts, local paths, command history, project names, and tool output. For OpenAI private support, attach raw logs only if they explicitly ask for them.

    Environment

    OS: Windows
    Codex package observed: OpenAI.Codex_26.519.5221.0_x64__<PACKAGE_SUFFIX_REDACTED>
    Codex desktop app version in Windows event log: 3044.0.0.0
    Codex app client version seen in logs: 26.519.41501
    Codex CLI/runtime binary observed: %LOCALAPPDATA%\OpenAI\Codex\bin\<HASH_REDACTED>\codex.exe
    

    Executive Summary

    I found one Windows-recorded Codex Desktop application hang, plus a much larger volume of Python native crashes occurring during the same general period.

    The Codex-specific hang was:

    Time: 2026-05-25 6:51:15 PM America/New_York
    Provider: Application Hang
    Event ID: 1002
    Program: Codex.exe
    Version: 3044.0.0.0
    Message: The program Codex.exe version 3044.0.0.0 stopped interacting with Windows and was closed.
    

    Windows Error Reporting recorded the matching app hang:

    Time: 2026-05-25 6:51:16 PM America/New_York
    Provider: Windows Error Reporting
    Event ID: 1001
    Event Name: MoAppHang
    P1: OpenAI.Codex_26.519.5221.0_x64__<PACKAGE_SUFFIX_REDACTED>
    P2: praid:App
    P3: 3044.0.0.0
    Report Id: <WER_REPORT_ID_REDACTED>
    Hashed bucket: <HASHED_BUCKET_REDACTED>
    WER archive path: C:\ProgramData\Microsoft\Windows\WER\ReportArchive\Critical_OpenAI.Codex_26._<REDACTED>
    

    The WER archive folder exists, but reading its contents from the diagnostic session returned:

    Access to the path ... is denied.
    

    So the event-log summary is available, but the hang dump/report contents were not readable without elevated Windows access.

    High-Volume Native Crashes

    In the last 24 hours, Windows Application logs showed:

    Windows Error Reporting, Event ID 1001: 357 matching events
    Application Error, Event ID 1000:      353 matching events
    Application Hang, Event ID 1002:         1 matching event
    

    Grouped by fault signature:

    python.exe / hnswlib / 0xc0000005          468 events
    pythonw.exe / python311.dll / 0xc00000fd   230 events
    Codex/OpenAI app hang                        2 WER/Application Hang records for the same hang
    

    Representative hnswlib access violation:

    Time: 2026-05-26 11:46:53 AM America/New_York
    Provider: Application Error
    Event ID: 1000
    Faulting application name: python.exe
    Faulting application version: 3.11.9150.1013
    Faulting module name: hnswlib.cp311-win_amd64.pyd
    Exception code: 0xc0000005
    Fault offset: 0x00000000000246f4
    Faulting process id: <PID_REDACTED>
    Faulting application path: C:\Program Files\Python311\python.exe
    Faulting module path: C:\Program Files\Python311\Lib\site-packages\hnswlib.cp311-win_amd64.pyd
    Report Id: <WER_REPORT_ID_REDACTED>
    

    Representative pythonw.exe stack overflow:

    Time: 2026-05-26 11:46:23 AM America/New_York
    Provider: Application Error
    Event ID: 1000
    Faulting application name: pythonw.exe
    Faulting application version: 3.11.9150.1013
    Faulting module name: python311.dll
    Exception code: 0xc00000fd
    Faulting application path: C:\Program Files\Python311\pythonw.exe
    Faulting module path: C:\Program Files\Python311\python311.dll
    Report Id: <WER_REPORT_ID_REDACTED>
    

    0xc0000005 is an access violation. 0xc00000fd is a stack overflow.

    Python Package Finding

    The crashing hnswlib.cp311-win_amd64.pyd was associated with chroma-hnswlib, not a standalone hnswlib Python package.

    Before remediation:

    Python executable: C:\Program Files\Python311\python.exe
    Python version: 3.11.9
    chroma-hnswlib: 0.7.6
    hnswlib metadata: PackageNotFoundError for package name hnswlib
    hnswlib module origin: C:\Program Files\Python311\Lib\site-packages\hnswlib.cp311-win_amd64.pyd
    chroma-hnswlib dist-info: C:\Program Files\Python311\Lib\site-packages\chroma_hnswlib-0.7.6.dist-info
    

    Package index check:

    chroma-hnswlib available versions: 0.7.6, 0.7.5, 0.7.3, 0.7.2, 0.7.1, 0.7.0
    Installed: 0.7.6
    Latest: 0.7.6
    

    No newer package version was available.

    Remediation Applied Locally

    1. Disabled an invalid Codex plugin entry.

    Codex config had:

    [plugins."chrome@openai-bundled"]
    enabled = true

    The cache path existed:

    %USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome\26.519.41501
    

    But it did not contain:

    .codex-plugin\plugin.json
    

    Codex logs repeatedly emitted:

    failed to load plugin: missing or invalid plugin.json plugin="chrome@openai-bundled"
    

    Local change applied:

    [plugins."chrome@openai-bundled"]
    enabled = false

    The valid browser plugin remains enabled:

    [plugins."browser@openai-bundled"]
    enabled = true
    1. Installed a clean user-level copy of chroma-hnswlib without changing dependencies.

    Command run:

    python.exe -m pip install --user --force-reinstall --no-deps chroma-hnswlib==0.7.6

    Result:

    Successfully installed chroma-hnswlib-0.7.6
    

    After remediation:

    hnswlib origin: %APPDATA%\Python\Python311\site-packages\hnswlib.cp311-win_amd64.pyd
    

    Smoke test:

    Created hnswlib Index(space='l2', dim=4)
    Initialized index
    Added 5 vectors
    Ran knn_query(k=2)
    Result: hnswlib smoke test ok
    

    This should cause normal user Python runs to load the user-profile copy instead of the system-wide Program Files copy.

    Codex Sandbox / Workspace Problem

    Codex was being run from C:\ in the diagnostic session. The config also marked c:\ as trusted:

    [projects.'c:\']
    trust_level = "trusted"

    Codex sandbox setup fails when trying to grant write access at the drive root:

    2026-05-26 11:03:14
    granting write ACE to C:\ for sandbox group and capability SID
    write ACE grant failed on C:\: SetNamedSecurityInfoW failed: 5
    setup refresh completed with errors: ["write ACE failed on C:\\: SetNamedSecurityInfoW failed: 5"]
    setup error: setup refresh had errors
    

    The same issue occurred again:

    2026-05-26 11:04:20
    write ACE grant failed on C:\: SetNamedSecurityInfoW failed: 5
    setup error: setup refresh had errors
    

    Codex SQLite logs then surface related execution failures:

    windows sandbox: runner error: CreateProcessAsUserW failed: 5
    

    Last 36 hours Codex ERROR summary:

    CreateProcessAsUserW failed: 5   56
    blocked by policy                20
    remote host closed connection     1
    other                            53
    

    Recommendation: do not use C:\ as a Codex workspace. Use a normal project directory such as:

    C:\Code\<project-name>
    %USERPROFILE%\<project-name>
    

    The drive root ACL failure is local/environmental and is distinct from the Codex Desktop MoAppHang.

    Other Codex Log Warnings

    Codex log locations, redacted:

    %USERPROFILE%\.codex\logs_2.sqlite
    %USERPROFILE%\.codex\log\codex-tui.log
    %USERPROFILE%\.codex\.sandbox\sandbox.log
    

    Recent warnings in logs_2.sqlite over the last 36 hours:

    ignored icon metadata:        2693
    missing plugin json:           124
    shell snapshot unsupported:    105
    Cloudflare/403 app list:         1
    tool suggestions failed:         1
    other:                         250
    

    Examples:

    failed to load plugin: missing or invalid plugin.json plugin="chrome@openai-bundled"
    
    Failed to create shell snapshot for powershell: Shell snapshot not supported yet for PowerShell
    
    failed to load discoverable tool suggestions: request failed with status 403 Forbidden
    

    The PowerShell shell snapshot warning appears informational. The invalid Chrome plugin warning was locally addressed by disabling the invalid plugin entry.

    Current Assessment

    Post-Restart Update

    After the user restarted Codex, I rechecked the live process list, Codex desktop state, Codex logs, and Windows Application logs.

    Findings as of approximately 2026-05-26 12:36 PM America/New_York:

    No new Codex.exe Application Hang event was found in the recent post-restart window.
    Codex.exe processes from 2026-05-26 11:00 AM were still running, so Codex does not appear to have fully terminated.
    A newer Codex app-server process was observed at 2026-05-26 12:36 PM.
    

    Codex Desktop rewrote its saved/active workspace state back to C:\ after the restart/current-thread resume:

    electron-saved-workspace-roots: ['C:\\', 'C:\\CyberSkyline', 'C:\\Code', 'C:\\AI_Vector']
    active-workspace-roots: ['C:\\']
    project-order: ['C:\\', 'C:\\CyberSkyline']
    

    This indicates the current thread/session is still anchored with cwd=C:\, and the desktop app is persisting that root workspace again while this thread remains active. The repair script at %USERPROFILE%\CodexWorkspaces\default\fix_codex_workspace_state.ps1 can re-apply the state fix, but a durable fix requires opening a new Codex session rooted at:

    %USERPROFILE%\CodexWorkspaces\default
    

    Final local observation: while this same root-anchored thread remains active, subsequent commands can cause active-workspace-roots to revert to C:\ again. This appears to be state persistence from the active thread, not a failure to create the dedicated workspace. The workspace fix should be applied after fully closing this root-anchored Codex session, then a new session should be opened from %USERPROFILE%\CodexWorkspaces\default.

    Recent Codex logs also still show the current turn/session using:

    cwd=C:\
    

    Post-restart Codex log summary over the recent check window:

    WARN/ERROR rows: 136
    codex_core_skills::loader icon warnings: 122
    codex_rollout::recorder parse warnings: 6
    PowerShell snapshot unsupported warnings: 3
    missing plugin json warnings: 2
    codex_core::tools::router errors: 2
    stream disconnected warning: 1
    

    The chrome@openai-bundled missing-plugin warning still appeared twice after restart, which suggests at least one running Codex process/thread had not picked up the updated config or was still using cached plugin state.

    Additional local remediation applied after this check:

    Stopped stale Chrome native extension host process from the broken cached Chrome plugin.
    
    Moved broken Chrome plugin cache out of active plugin cache:
      From: %USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome
      To:   %USERPROFILE%\.codex\plugins\disabled-cache\openai-bundled\chrome.disabled-<TIMESTAMP>
            %USERPROFILE%\.codex\plugins\disabled-cache\openai-bundled\chrome.remaining-disabled-<TIMESTAMP>
    

    Final verification:

    %USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome exists: False
    No stale extension-host.exe process remained from the broken Chrome plugin cache.
    chrome@openai-bundled remains disabled in config.
    browser@openai-bundled remains enabled in config.
    

    Windows Application logs since 2026-05-26 12:00 PM America/New_York showed additional Python crashes:

    pythonw.exe / python311.dll / 0xc00000fd: 16 records
    python.exe / hnswlib / 0xc0000005:        12 records
    

    Representative recent hnswlib crash:

    Time: 2026-05-26 12:32:30 PM America/New_York
    Faulting application name: python.exe
    Faulting module name: hnswlib.cp311-win_amd64.pyd
    Exception code: 0xc0000005
    Faulting application path: C:\Program Files\Python311\python.exe
    Faulting module path: C:\Program Files\Python311\Lib\site-packages\hnswlib.cp311-win_amd64.pyd
    Report Id: <WER_REPORT_ID_REDACTED>
    

    Representative recent pythonw.exe crash:

    Time: 2026-05-26 12:35:54 PM America/New_York
    Faulting application name: pythonw.exe
    Faulting module name: python311.dll
    Exception code: 0xc00000fd
    Faulting application path: C:\Program Files\Python311\pythonw.exe
    Faulting module path: C:\Program Files\Python311\python311.dll
    Report Id: <WER_REPORT_ID_REDACTED>
    

    The continued C:\Program Files\Python311\Lib\site-packages\hnswlib.cp311-win_amd64.pyd fault path means the user-level chroma-hnswlib mitigation is not affecting all running Python workloads. Some running scripts/services are still using the system-level Python/site-packages, or were launched before the user-level override could take effect.

    The system-level and user-level hnswlib.cp311-win_amd64.pyd binaries were compared and are byte-for-byte identical. The exact hash is omitted from this redacted report.

    Therefore, reinstalling the same package into C:\Program Files\Python311\Lib\site-packages would not change the native binary. Remaining Python crashes appear to be workload/runtime related rather than a corrupted local hnswlib file.

    What was likely local and addressed:

    • Repeated invalid plugin warnings from chrome@openai-bundled were addressed by disabling that stale/invalid plugin entry.
    • Python native crashes involving C:\Program Files\Python311\Lib\site-packages\hnswlib.cp311-win_amd64.pyd were mitigated by installing a user-level copy of chroma-hnswlib==0.7.6, which now takes precedence in Python imports.
    • The C:\ trusted project entry was replaced with %USERPROFILE%\CodexWorkspaces\default.
    • Codex Desktop's saved/active workspace roots were updated in both %USERPROFILE%\.codex\.codex-global-state.json and %USERPROFILE%\.codex\.codex-global-state.json.bak so Codex stops reopening at the drive root.
    • A backup of the prior desktop state was saved locally.
    • A repair script was added at %USERPROFILE%\CodexWorkspaces\default\fix_codex_workspace_state.ps1 to re-apply the workspace-state fix if Codex rewrites C:\ back into its desktop state while closing.
    • The broken cached chrome@openai-bundled plugin folder was moved out of the active plugin cache after stopping its stale native extension host process.

    What remains environmental:

    • Codex sandbox command execution can fail when the workspace is C:\ because Codex tries to grant ACLs at the drive root and receives Windows access denied (SetNamedSecurityInfoW failed: 5). This was partially mitigated by creating a non-root workspace directory, but the current resumed thread is still anchored to C:\ and is causing Codex Desktop to persist C:\ again.
    • Python crash records continue after the user-level chroma-hnswlib install, indicating some Python workloads are still using the system-level package under C:\Program Files\Python311.

    What remains for OpenAI if it recurs:

    • The Codex Desktop MoAppHang on 2026-05-25 6:51 PM EDT should be investigated if it happens again, especially if hangs continue after:
      • avoiding C:\ as the workspace;
      • disabling the invalid Chrome plugin entry;
      • mitigating the Python hnswlib native crash.

    Suggested OpenAI Support Summary

    Codex Desktop on Windows hung and was closed by Windows on 2026-05-25 at 6:51 PM EDT. Windows logged Application Hang Event ID 1002 for Codex.exe version 3044.0.0.0, with WER Event ID 1001 MoAppHang for package OpenAI.Codex_26.519.5221.0_x64__<PACKAGE_SUFFIX_REDACTED>.

    Local diagnostics also found a stale enabled plugin entry chrome@openai-bundled whose cache did not contain .codex-plugin\plugin.json, producing repeated missing or invalid plugin.json warnings. That entry was disabled while keeping browser@openai-bundled enabled.

    There are also sandbox failures when the workspace is rooted at C:\: write ACE failed on C:\: SetNamedSecurityInfoW failed: 5, later surfacing as windows sandbox: runner error: CreateProcessAsUserW failed: 5. The user should avoid C:\ as a workspace.

    Separately, Windows logged hundreds of native Python crashes involving python.exe and pythonw.exe, especially hnswlib.cp311-win_amd64.pyd access violations (0xc0000005) and python311.dll stack overflows (0xc00000fd). A clean user-level chroma-hnswlib==0.7.6 install was applied so Python now imports hnswlib from the user profile rather than C:\Program Files\Python311\Lib\site-packages.

    Files to Reference Privately

    If submitting a private OpenAI support ticket, reference these locations after replacing placeholders with local paths as needed:

    %USERPROFILE%\.codex\logs_2.sqlite
    %USERPROFILE%\.codex\log\codex-tui.log
    %USERPROFILE%\.codex\.sandbox\sandbox.log
    %USERPROFILE%\.codex\config.toml
    Windows Event Viewer > Windows Logs > Application
    

    Do not publicly attach the raw files above. They may contain command history, prompts, local project paths, and other sensitive context.

    The WER archive folder exists but may require Administrator access to read:

    C:\ProgramData\Microsoft\Windows\WER\ReportArchive\Critical_OpenAI.Codex_26._<REDACTED>
    
  7. grnbtqdbyx-create commented on May 31, 2026

    @grnbtqdbyx-create

    This issue is a good example of the gap between "not enough detail" and "please do not post raw local Codex files publicly".

    For future crash/repro reports, I published a small local helper that packages the safer parts of the same evidence shape:

    npx trace-to-skill@latest diagnostics-bundle ~/.codex --output codex-diagnostics

    It writes a metadata-only folder with a manifest, README, config audit, and session audit summaries. It intentionally does not copy raw config.toml, logs_2.sqlite, state_5.sqlite, session_index.jsonl, rollout JSONL, or local Codex logs.

    Release/schema for maintainers who want to inspect the exact contract:

    Not claiming this diagnoses the crash by itself; it is meant to make the next "please provide more detail" round safer and more structured.

  8. FinMonkeys commented on Jun 2, 2026

    @FinMonkeys

    019e36d2-c9a8-70d0-9143-7352a6788b8c

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