[CLI 0.162.1][WSL Ubuntu] Repeated capacity errors during remote compaction block work for 3+ hours; minimal fresh task succeeds #53323

What version of Codex CLI is running?

codex-cli 0.162.1 (confirmed with codex --version).

What subscription do you have?

ChatGPT Pro.

Which model were you using?

The affected-session screenshot displays GPT-6.1-Sol high fast. Switching models was attempted and did not resolve the recurring problem. The exact identifiers of the other models tested were not recorded.

What platform is your computer?

Windows with Codex CLI running inside WSL Ubuntu. Exact Windows, Ubuntu, and kernel versions have not been collected.

What terminal emulator and version are you using (if applicable)?

Terminal running WSL Ubuntu; exact emulator version not collected.

Codex doctor report

Not collected. No doctor output or uploaded diagnostic/thread ID is available with this report.

What issue are you seeing?

Frequent capacity errors make normal coding work unusable. This persisted for more than three hours during the reported incident on October 12, 2026 (UTC+8), and continued despite troubleshooting.

The affected-session screenshot repeatedly shows the full error:

Error running remote compact task: Selected model is at capacity. Please try a different model.

Repeated manual attempts to continue the interrupted task each hit the same error. Even sending hi within that affected session produced the same remote-compaction error. This is a repeated failure on user retries, not evidence that the client is automatically retrying indefinitely.

What steps can reproduce the bug?

Observed failure pattern, not yet an independently reproducible minimal failing case:

1. Run Codex CLI in WSL Ubuntu and work on a project task.
2. The session reaches a remote-compaction attempt and reports the error above.
3. Ask the session to continue; the same remote-compaction error recurs and work cannot progress.
4. Switching models and exiting/reopening sessions did not provide a lasting resolution.

Important successful control test: A fresh session in a separate test directory under the Ubuntu home directory, started with:

codex "reply only OK"

returned OK. Therefore, this report does not claim that every fresh request or all account access fails. Short fresh requests can work while normal project work remains frequently blocked.

What is the expected behavior?

Normal coding tasks should remain usable. If capacity is temporarily unavailable during compaction, preserve the task and provide an actionable, recoverable waiting/retry path rather than repeatedly blocking continuation with only a suggestion to switch models. Any model fallback should be explicit and respect the user's choice.

Additional information

Confirmed troubleshooting/results:

• Switched models: recurring problem remained.
• Exited and reopened sessions: recurring problem remained.
• Fresh minimal task outside the project: successfully returned OK.
• The problem persisted for more than three hours and still prevents reliable normal use.

An earlier troubleshooting suggestion used codex --ephemeral, which this installation rejected with unexpected argument '--ephemeral' found. That command did not execute a diagnostic task and is not counted as a failed model request.

Please investigate the capacity failures on the remote-compaction path and advise on a safe recovery method that preserves existing work and session history. The available evidence does not establish the backend cause, session corruption, or an account-wide restriction; no HTTP status or request ID has been captured.

Related reports found before filing: #53256 (capacity errors on CLI 0.162.0) and #50238 (recoverable capacity handling, including compaction). This report adds CLI 0.162.1 / WSL Ubuntu observations, repeated compaction failures over 3+ hours, and a successful fresh minimal-task control. Please consolidate if appropriate.

Private project names, local paths, source code, account identifiers, credentials, and raw session logs have deliberately been omitted. The screenshot's error text is transcribed above rather than publishing the unredacted screenshot.