[Windows][Desktop] OOM leaves intact local tasks missing from sidebar; /feedback also crashes and recovery consumes heavy usage

Summary

Codex Desktop on Windows restarted during a resource-exhaustion event. After restart, two existing local tasks disappeared from the project/sidebar even though their rollout files and index/state records were still present and readable. They were not deleted or archived.

Trying to report the problem through the documented /feedback flow by resuming an affected task loaded the long history, started MCP servers, and then exited with:

memory allocation of 1403200 bytes failed

So the in-product feedback path could not be used for this incident.

This appears to combine four failure modes:

1. unbounded or overly eager hydration of a long task;
2. loss of sidebar/project membership while durable task data remains intact;
3. no supported reindex/recover action for an orphaned task;
4. unusually high agentic usage consumed while merely attempting recovery.

Environment

• Codex Desktop package: 26.707.3748.0
• Bundled Codex CLI: 0.144.0-alpha.4
• Windows 11 x64: 10.0.26200
• Incident date: 2026-07-12 (UTC+8)

Evidence

• Windows Resource-Exhaustion-Detector Event ID 2004 was recorded three times within about 22 minutes.
• At each event, three python.exe processes were the largest consumers at approximately 1.23-1.26 GiB each. Historical command lines were unavailable, so I cannot reliably attribute those processes to a specific extension or MCP server.
• Codex logs around the same period showed repeated child-process snapshot failures, Git waitFailed/spawnFailed errors, and a Desktop instance restart.
• The affected rollout files remained valid. One was approximately 6-7 MB with more than 2,000 JSONL records.
• The task index/state database still contained the affected tasks and they could be addressed by task-reading tooling.
• Both tasks were active, but frontend project membership was absent: neither task was assigned to the current project nor categorized as projectless. One affected task was pinned and still did not appear normally.
• Restarting Desktop did not rebuild the missing sidebar entries.
• A diagnostic manual edit of frontend global state was overwritten on restart. This is not proposed as a workaround; it suggests that another state source wins during startup without repairing the orphaned mapping.

Usage impact

During recovery attempts, the user did essentially no project work, but the five-hour usage meter fell by roughly 50%.

Local telemetry for the long task showed model steps with about 200k-220k input tokens each, mostly cached. The cumulative transcript telemetry was much larger because repeated tool/model turns and subagent forks continued to carry a very large context. The native /feedback attempt itself resumed the full task, initialized MCP, and failed before the feedback dialog appeared.

This makes task recovery unexpectedly expensive and can prevent the report from being filed through the preferred channel.

Steps that reproduce the observed sequence

1. Use a long, tool-heavy Desktop task on Windows, including compaction, MCP tools, and multiple subagents.
2. Encounter severe memory pressure and a Desktop restart.
3. Confirm that rollout/index data still exists and task-reading APIs can load the task.
4. Observe that the task is absent from its project/sidebar after restart.
5. Restart Desktop again; the task remains hidden.
6. Resume the affected task and invoke /feedback.
7. Desktop/CLI eagerly hydrates the long task and starts MCP processes; under constrained memory it exits before feedback can be submitted.

The exact memory-pressure trigger may vary, but the durable-data/sidebar inconsistency persisted after the crash.

Expected behavior

• Task history should be loaded lazily or in bounded pages, especially for sidebar recovery and /feedback.
• Sidebar/project membership should be reconstructable from authoritative task data when frontend mapping is missing.
• Desktop should provide a supported Reindex / Recover local tasks action with a dry-run preview.
• /feedback should remain lightweight and usable even when the current task is huge or damaged; it should not need to hydrate the entire task or start unrelated MCP servers.
• Resuming a very large context or forking full-context subagents should show an estimated usage impact or warning.
• A crash should not leave readable, active tasks undiscoverable in the main UI.

Related issues

• #25779
• #17083
• #14593
• #28094

Privacy

The affected task concerns a private healthcare software project. No transcript, local path, account identifier, patient information, or project content is included here. Sanitized diagnostics can be provided privately if an OpenAI maintainer offers an appropriate channel.