Codex Desktop repeatedly fails with model capacity errors during long tasks and compaction

Environment

• Windows 11 Home, 64-bit, build 26200
• Official Codex Desktop/OpenAI connection; no custom model provider
• ChatGPT Pro
• Codex Desktop product version: 153.0.8010.36
• Installed package path indicates build 26.911.7940.0
• Codex session CLI version: 0.155.0-alpha.2.6
• Current configured model: gpt-5.6-sol
• Model provider recorded in session metadata: openai

Issue

For several days, long-running Codex tasks intermittently fail with:

Selected model is at capacity. Please try a different model.
codex_error_info: server_overloaded

Local Codex session logs confirm the following occurrences:

The failures commonly occur after a tool or shell operation has completed, when the model should continue. New short tasks can sometimes work normally while an existing long task fails repeatedly.

The UI also reported:

Error running remote compact task: Selected model is at capacity.

I could not find that exact phrase in the local JSONL session records, so please correlate it with server-side diagnostics. The local records do confirm the server_overloaded capacity failures.

Impact

Long-running research workflows become unreliable because the task cannot continue after tool calls or automatic context compaction. Users may need to reconstruct context and resume manually.

Requested investigation

1. Check model-capacity routing for long-running sessions and whether it differs from short tasks.
2. Check remote-compaction retry/fallback behavior.
3. Check whether completed tool-call state is preserved when model continuation fails.
4. Check whether this Desktop/CLI version combination is associated with the issue.

Feedback ID

Not yet available. The in-app /feedback entry could not be reached from the current desktop state; I will add the Feedback ID if it becomes available.

No API keys, tokens, cookies, project contents, or private file paths are included in this report.

Start with the local JSONL session records and the remote compact task path, then trace how server_overloaded is handled after tool or shell completion. Reproduce a long-running task and compare it with a short task, checking retry/fallback and preservation of completed tool-call state. Done means the failure is correlated with diagnostics and its handling is corrected or clearly documented.