You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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
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:
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:
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:
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
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:
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:
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:
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
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:
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:
Activity
github-actions commentedon May 26, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
etraut-openai commentedon May 26, 2026
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 commentedon May 26, 2026
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:
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
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:
Windows Error Reporting recorded the matching app hang:
The WER archive folder exists, but reading its contents from the diagnostic session returned:
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:
Grouped by fault signature:
Representative
hnswlibaccess violation:Representative
pythonw.exestack overflow:0xc0000005is an access violation.0xc00000fdis a stack overflow.Python Package Finding
The crashing
hnswlib.cp311-win_amd64.pydwas associated withchroma-hnswlib, not a standalonehnswlibPython package.Before remediation:
Package index check:
No newer package version was available.
Remediation Applied Locally
Codex config had:
The cache path existed:
But it did not contain:
Codex logs repeatedly emitted:
Local change applied:
The valid browser plugin remains enabled:
chroma-hnswlibwithout changing dependencies.Command run:
Result:
After remediation:
Smoke test:
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 markedc:\as trusted:Codex sandbox setup fails when trying to grant write access at the drive root:
The same issue occurred again:
Codex SQLite logs then surface related execution failures:
Last 36 hours Codex ERROR summary:
Recommendation: do not use
C:\as a Codex workspace. Use a normal project directory such as:The drive root ACL failure is local/environmental and is distinct from the Codex Desktop
MoAppHang.Other Codex Log Warnings
Codex log locations, redacted:
Recent warnings in
logs_2.sqliteover the last 36 hours:Examples:
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:
chrome@openai-bundledwere addressed by disabling that stale/invalid plugin entry.C:\Program Files\Python311\Lib\site-packages\hnswlib.cp311-win_amd64.pydwere mitigated by installing a user-level copy ofchroma-hnswlib==0.7.6, which now takes precedence in Python imports.What remains environmental:
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:
MoAppHangon 2026-05-25 6:51 PM EDT should be investigated if it happens again, especially if hangs continue after:C:\as the workspace;hnswlibnative 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 HangEvent ID 1002 forCodex.exeversion3044.0.0.0, with WER Event ID 1001MoAppHangfor packageOpenAI.Codex_26.519.5221.0_x64__<PACKAGE_SUFFIX_REDACTED>.Local diagnostics also found a stale enabled plugin entry
chrome@openai-bundledwhose cache did not contain.codex-plugin\plugin.json, producing repeatedmissing or invalid plugin.jsonwarnings. That entry was disabled while keepingbrowser@openai-bundledenabled.There are also sandbox failures when the workspace is rooted at
C:\:write ACE failed on C:\: SetNamedSecurityInfoW failed: 5, later surfacing aswindows sandbox: runner error: CreateProcessAsUserW failed: 5. The user should avoidC:\as a workspace.Separately, Windows logged hundreds of native Python crashes involving
python.exeandpythonw.exe, especiallyhnswlib.cp311-win_amd64.pydaccess violations (0xc0000005) andpython311.dllstack overflows (0xc00000fd). A clean user-levelchroma-hnswlib==0.7.6install was applied so Python now importshnswlibfrom the user profile rather thanC:\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:
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:
Hal9000AIML commentedon May 26, 2026
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:
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
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:
Windows Error Reporting recorded the matching app hang:
The WER archive folder exists, but reading its contents from the diagnostic session returned:
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:
Grouped by fault signature:
Representative
hnswlibaccess violation:Representative
pythonw.exestack overflow:0xc0000005is an access violation.0xc00000fdis a stack overflow.Python Package Finding
The crashing
hnswlib.cp311-win_amd64.pydwas associated withchroma-hnswlib, not a standalonehnswlibPython package.Before remediation:
Package index check:
No newer package version was available.
Remediation Applied Locally
Codex config had:
The cache path existed:
But it did not contain:
Codex logs repeatedly emitted:
Local change applied:
The valid browser plugin remains enabled:
chroma-hnswlibwithout changing dependencies.Command run:
Result:
After remediation:
Smoke test:
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 markedc:\as trusted:Codex sandbox setup fails when trying to grant write access at the drive root:
The same issue occurred again:
Codex SQLite logs then surface related execution failures:
Last 36 hours Codex ERROR summary:
Recommendation: do not use
C:\as a Codex workspace. Use a normal project directory such as:The drive root ACL failure is local/environmental and is distinct from the Codex Desktop
MoAppHang.Other Codex Log Warnings
Codex log locations, redacted:
Recent warnings in
logs_2.sqliteover the last 36 hours:Examples:
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:
Codex Desktop rewrote its saved/active workspace state back to
C:\after the restart/current-thread resume: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.ps1can re-apply the state fix, but a durable fix requires opening a new Codex session rooted at:Final local observation: while this same root-anchored thread remains active, subsequent commands can cause
active-workspace-rootsto revert toC:\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:
Post-restart Codex log summary over the recent check window:
The
chrome@openai-bundledmissing-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:
Final verification:
Windows Application logs since 2026-05-26 12:00 PM America/New_York showed additional Python crashes:
Representative recent
hnswlibcrash:Representative recent
pythonw.execrash:The continued
C:\Program Files\Python311\Lib\site-packages\hnswlib.cp311-win_amd64.pydfault path means the user-levelchroma-hnswlibmitigation 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.pydbinaries 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-packageswould not change the native binary. Remaining Python crashes appear to be workload/runtime related rather than a corrupted localhnswlibfile.What was likely local and addressed:
chrome@openai-bundledwere addressed by disabling that stale/invalid plugin entry.C:\Program Files\Python311\Lib\site-packages\hnswlib.cp311-win_amd64.pydwere mitigated by installing a user-level copy ofchroma-hnswlib==0.7.6, which now takes precedence in Python imports.C:\trusted project entry was replaced with%USERPROFILE%\CodexWorkspaces\default.%USERPROFILE%\.codex\.codex-global-state.jsonand%USERPROFILE%\.codex\.codex-global-state.json.bakso Codex stops reopening at the drive root.%USERPROFILE%\CodexWorkspaces\default\fix_codex_workspace_state.ps1to re-apply the workspace-state fix if Codex rewritesC:\back into its desktop state while closing.chrome@openai-bundledplugin folder was moved out of the active plugin cache after stopping its stale native extension host process.What remains environmental:
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 toC:\and is causing Codex Desktop to persistC:\again.chroma-hnswlibinstall, indicating some Python workloads are still using the system-level package underC:\Program Files\Python311.What remains for OpenAI if it recurs:
MoAppHangon 2026-05-25 6:51 PM EDT should be investigated if it happens again, especially if hangs continue after:C:\as the workspace;hnswlibnative 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 HangEvent ID 1002 forCodex.exeversion3044.0.0.0, with WER Event ID 1001MoAppHangfor packageOpenAI.Codex_26.519.5221.0_x64__<PACKAGE_SUFFIX_REDACTED>.Local diagnostics also found a stale enabled plugin entry
chrome@openai-bundledwhose cache did not contain.codex-plugin\plugin.json, producing repeatedmissing or invalid plugin.jsonwarnings. That entry was disabled while keepingbrowser@openai-bundledenabled.There are also sandbox failures when the workspace is rooted at
C:\:write ACE failed on C:\: SetNamedSecurityInfoW failed: 5, later surfacing aswindows sandbox: runner error: CreateProcessAsUserW failed: 5. The user should avoidC:\as a workspace.Separately, Windows logged hundreds of native Python crashes involving
python.exeandpythonw.exe, especiallyhnswlib.cp311-win_amd64.pydaccess violations (0xc0000005) andpython311.dllstack overflows (0xc00000fd). A clean user-levelchroma-hnswlib==0.7.6install was applied so Python now importshnswlibfrom the user profile rather thanC:\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:
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:
grnbtqdbyx-create commentedon May 31, 2026
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-diagnosticsIt 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 commentedon Jun 2, 2026
019e36d2-c9a8-70d0-9143-7352a6788b8c