codex - 💡(How to fix) Fix Codex Desktop 0.131.0-alpha.9 crashes/reloads after completed long sessions on Windows; possible regression from 0.130

What happened?

Codex Desktop on Windows repeatedly appears to crash, reload, or disconnect after long project tasks. In several cases the agent had already completed the task and emitted task_complete, but the Desktop UI became unusable or the conversation had to be reopened/recovered.

This seems different from a normal project/tool failure: the task itself can finish successfully, including shell commands, commit/push, and the final answer, but the Desktop app becomes unstable immediately afterward.

Environment

• OS: Windows 11 Pro, build 26200
• RAM: about 31.7 GB
• Codex Desktop package: OpenAI.Codex_26.513.3673.0_x64__2p2nqsd0c76g0
• Codex Desktop session metadata version: 0.131.0-alpha.9
• Model/effort involved: mostly gpt-5.5 with high / xhigh
• Workspace type: large real coding project, many shell commands and local validation gates

Concrete session evidence

Relevant thread IDs:

• 019e3090-f317-7d22-a3e6-3e298962fc3b
• 019e30e4-ee12-7623-a5a5-cb580828d301
• 019e3122-9cd6-72f2-8ebb-410a1cbaf721
• 019e3135-1358-7753-86fa-7f58256011ce

For thread 019e3122-9cd6-72f2-8ebb-410a1cbaf721:

• Started around 2026-05-16 22:13:32 local time
• Reached final answer and task_complete around 2026-05-16 22:33:24
• Duration in task_complete: about 19m 51s
• Shell calls recorded: 107
• Compactions recorded: 14
• Last total token usage: 10,855,168
• Max observed single-turn input in token events: about 244,482 input tokens
• Warnings mentioning the thread included many plugin/skill loader warnings:
  • codex_core_plugins::manifest: 105
  • codex_core_skills::loader: 180
  • codex_core::shell_snapshot: 1
• Tool-router errors were non-zero shell command exits; the task recovered and completed.

Windows Application logs did not show a matching Codex process crash during the latest failures, and Codex processes often remained running. This makes renderer/session/UI state, final-answer rendering, command-history rendering, session archival, or post-task UI update paths suspicious.

Possible regression evidence

The same user reports that the same workflow did not crash before updating/reinstalling Codex. Local .codex backups support treating this as a possible regression rather than only a project-size issue.

Older sessions from C:\Users\Administrator\.codex.zip included:

• 0.130.0-alpha.5: 37 sessions, 37 with task_complete; 10 sessions larger than 5 MB; largest about 54.1 MB.
• 0.128.0-alpha.1: 11 sessions, 11 with task_complete; largest about 62.1 MB.
• 0.125.0-alpha.3: 10 sessions, 10 with task_complete; largest about 30.9 MB.
• 0.112.0-alpha.3: 29 sessions, 28 with task_complete; 10 sessions larger than 5 MB; largest about 23.5 MB.

By comparison, the current unstable version is 0.131.0-alpha.9, and one observed unstable session (019e3122...) was only about 1.4 MB yet still led to a Desktop failure after successful task completion.

Additional related symptom

A later thread, 019e3135-1358-7753-86fa-7f58256011ce, showed stream instability:

• Multiple stream disconnected - retrying sampling request events
• Five retries, then falling back to HTTP
• Token usage continued growing through repeated follow-up sampling
• At inspection time, no task_complete was present

So there may be two overlapping failure modes:

1. Large completed sessions make the Desktop UI/session layer unstable after the final answer.
2. Streaming disconnect/fallback can leave a heavy project thread in a fragile state.

State/cache observations

Stability-related settings appeared to be overwritten while Codex Desktop was still running:

• conversationDetailMode reverted to STEPS_COMMANDS
• electron:onboarding-plugin-checklist-active reverted to true
• C:\Users\Administrator\.codex\.tmp regenerated plugin marketplace/plugin cache

The .tmp plugin cache had about 4,090 entries and about 17 MB after restart. The active logs DB was about 116 MB:

• C:\Users\Administrator\.codex\logs_2.sqlite
• C:\Users\Administrator\.codex\logs_2.sqlite-wal

An earlier pre-reinstall logs DB had grown to about 497 MB.

Why this matters

This is a realistic heavy coding workflow, not an artificial stress test: long-running repo tasks, many shell commands, multiple validation gates, project skills, high reasoning effort, and repeated daily use. The machine has enough memory, and older Codex versions appear to have handled even larger sessions.

Requested improvements

• Make Codex Desktop robust when rendering or archiving completed sessions with many command calls.
• Add a cap or virtualization for command-history rendering in STEPS_COMMANDS.
• Ensure settings like conversationDetailMode and plugin checklist enablement persist correctly after being changed.
• Avoid loading/scanning plugin checklist assets when the checklist is disabled.
• Improve stream disconnect/fallback handling so retry storms do not leave Desktop sessions unstable.
• Provide an official log/cache pruning control for large logs_2.sqlite, .tmp, and old session artifacts.
• Surface clearer diagnostics to the user: renderer crash vs session process failure vs network stream failure.

Related issues that look similar or adjacent: #22004, #21134, #18723.