›_ Codex Issues
Codex Issues / #24598

Codex randomly crashes

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

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_

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 1 month ago

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

  • #23814

Powered by Codex Action

etraut-openai contributor · 1 month ago

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.

Hal9000AIML · 1 month ago

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>
Hal9000AIML · 1 month ago

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>
grnbtqdbyx-create · 1 month ago

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.

FinMonkeys · 1 month ago

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