Codex Desktop: remote-compaction capacity error terminalizes one persistent goal while other tasks remain healthy

[adpena]

What version of Codex are you using?

• Codex Desktop on Windows
• codex-cli 0.144.1 (subagent logs also reported 0.144.2)
• ChatGPT-authenticated
• Active model: gpt-5.6-sol, reasoning effort xhigh

What issue are you seeing?

A long-running persistent /goal task repeatedly reaches remote compaction and fails with:

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

It then also surfaces:

Selected model is at capacity. Please try a different model.

The recoverable capacity/compaction failure is converted into terminal control-plane state:

1. The goal changes from active to blocked.
2. Automatic continuation stops and the user must send another message.
3. The repository and shell remain healthy.
4. Calling the goal creation API to replace/recover the task fails with:
   cannot create a new goal because this thread has an unfinished goal; complete the existing goal first
5. The API therefore simultaneously treats the goal as terminally blocked and unfinished.
6. Subagents forked from the affected task can also receive the same capacity error.

This task has accumulated more than 25 million total goal tokens across many compactions. The failure has recurred for several hours.

Strong control observation

At the same time, on the same Windows machine, Codex Desktop app, authenticated account, and service window, a separate task in another repository continues to work normally with no capacity failure.

That makes blanket account quota exhaustion or a global model outage unlikely. The failure appears scoped to the long-lived task's remote-compaction/admission/recovery path. Available usage is not a sufficient explanation because the healthy control task continues normally.

Reproduction

1. Start a persistent /goal in Codex Desktop.
2. Run it long enough to cross many automatic compactions and automatic continuations.
3. Let a remote compact request receive a transient model-capacity response.
4. Observe the goal becoming blocked and continuation stopping.
5. Send a user message to resume; work can proceed, but the goal API still reports stale blocked/unfinished state.
6. Compare with another task on the same account/app, which remains healthy.

I can provide the affected task ID privately if maintainers need it.

Expected behavior

A transient remote-compaction capacity error must not terminalize a persistent goal.

• Retry with bounded backoff, or fall back to a supported local/dedicated compaction model.
• Keep the goal active across recoverable compaction/admission failures.
• If continuation cannot proceed immediately, preserve a recoverable state rather than blocked.
• Allow an explicitly resumed user turn to clear stale blocked state.
• Do not let create_goal deadlock on a state considered both blocked and unfinished.
• Distinguish account quota, model admission, compact-endpoint capacity, and task-state failures in the UI.

Related issues

• Context compact error #21343: remote compaction failures can strand long sessions (closed)
• Codex CLI recommends gpt-5.4, then fails with 'Selected model is at capacity' despite available quota #17014 and Selected model is at capacity #19583: capacity errors despite available quota (closed)
• auto compaction - expose compaction to agent #21777: goal-aware compaction controls (open)
• Add an option to disable remote compaction and use local fallback in the CLI #24418: local fallback / disable remote compaction (open)
• Codex Desktop: automatic context compaction cannot be cancelled and can stall long-running tasks #24432: Desktop auto-compaction can stall long-running tasks (open)

This report is distinct because it includes a same-account healthy control task and the stale blocked + unfinished goal-state deadlock.

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• Regression: Windows Desktop 26.707.3748 remote compaction disconnects after update #32545
• Active goal auto-resume after an unclean restart leaves interrupted lifecycle state and diverges from persisted goal status after context-full retries (autogen selfreport from codex) #32973

Powered by Codex Action

[adpena]

I checked current openai/codex main after filing. There is no safe user-side local-compaction switch:

• codex-rs/core/src/compact.rs::should_use_remote_compact_task returns only provider.supports_remote_compaction().
• codex-rs/core/src/tasks/compact.rs uses remote_compaction_v2 only to select compact_remote_v2 versus legacy compact_remote.
• Disabling remote_compaction_v2 therefore does not select local compaction for ChatGPT auth.
• The local branch is reachable only when the provider says remote compaction is unsupported.

So the installed stable feature flag cannot safely mitigate this failure. The needed fix is provider/model/endpoint-aware fallback plus recovery of goal state after a failed compact request.

Source:

• https://github.com/openai/codex/blob/main/codex-rs/core/src/compact.rs
• https://github.com/openai/codex/blob/main/codex-rs/core/src/tasks/compact.rs

[adpena]

A working local mitigation is now proven on 0.144.1, though it relies on current implementation detail and should not replace a product fix.

Custom ChatGPT-authenticated provider:

model_provider = "openai-local-compact"

[model_providers."openai-local-compact"]
name = "OpenAI Local Compaction"
base_url = "https://chatgpt.com/backend-api/codex"
wire_api = "responses"
requires_openai_auth = true
supports_websockets = false
request_max_retries = 4
stream_max_retries = 8
stream_idle_timeout_ms = 300000

Why it works on current main:

• normal inference/auth still use the official direct ChatGPT Codex endpoint
• ModelProviderInfo::supports_remote_compaction() selects remote compaction only when name == "OpenAI" (or Azure)
• the distinct display name selects the existing local compaction implementation

Proof on Windows / CLI 0.144.1:

1. app-server normal turn completed
2. JSON-RPC thread/compact/start completed
3. rollout persisted model_provider: "openai-local-compact"
4. rollout persisted a compacted record with generated summary
5. no remote compact event/error appeared
6. post-compaction turn completed successfully
7. a separate new CLI task using the global default persisted the same provider and completed

This is deliberately a mitigation, not the desired API. A supported config such as compaction = "auto|remote|local", with automatic remote-to-local fallback, would avoid depending on provider display-name identity.

[adpena]

Additional reproducible evidence from Codex desktop 0.144.1 on Windows (2026-07-14): after remote compaction returned Selected model is at capacity, the active goal persisted as status=blocked. Multiple explicit user resume / continue messages and substantial successful tool work did not clear it; the goal API still reports blocked while a queue-custodied repository proof is actively running. Work can continue only by ignoring the badge, and there is no resume/reopen/replacement path exposed by the goal API. The same account and selected model continued working normally in another repository task during this period, so the failure appears thread-specific rather than a global model-capacity outage.

Expected behavior: a transient remote-compaction capacity failure should retry or fall back without converting the goal into terminal blocked state; otherwise the goal must be explicitly resumable and the UI/API state must reconcile with ongoing work.

[adpena]

Additional deterministic control-plane evidence from the same affected desktop task:

• get_goal returns the goal with status: "blocked".
• After the user explicitly resumes the work, the goal remains blocked.
• Attempting to replace it with create_goal fails: cannot create a new goal because this thread has an unfinished goal; complete the existing goal first.
• The exposed goal API has no resume transition; update_goal accepts only complete or blocked.

This leaves the task in a contradictory state: blocked enough to stop automatic continuation, but unfinished enough to forbid a replacement. The original transition followed a remote-compaction/model-capacity failure, while another concurrent Codex task remained healthy. A manual thread heartbeat can re-enter the task as a workaround, but the Goal state machine needs an idempotent resume/recovery transition after user input and compaction/capacity failure.

[the1337moderator]

I observed a related capacity failure on a long-running ordinary local task (not a persistent /goal), with an additional task-discovery failure.

Environment:

• Codex Desktop package: 26.707.9981.0
• Windows 11 Pro x64: 10.0.26200
• Local worktree-backed task
• No session, prompt, transcript, task ID, repository information, or source code is attached

Observed behavior:

1. The task ran for approximately 1 hour 58 minutes.
2. Desktop displayed a model-capacity error.
3. The active turn ended abruptly without producing a final agent message.
4. The task's durable history and worktree changes remained intact, but the task was no longer available through the normal working view.
5. A different Codex task could locate it using internal task-management tooling, which reported the target as notLoaded.
6. Direct navigation to the located task reopened it and allowed the user to continue.

This broadens the failure beyond persistent goals: a capacity error can terminalize an ordinary long-running turn and also strand the intact task in a state that requires another model session to recover.

Expected behavior:

• Treat capacity/admission failures as transient and retryable.
• Preserve the task in the sidebar with an explicit Retry/Resume action.
• Never require a second paid/model-mediated task to locate and reopen durable local history.
• Provide a non-model task manager or recovery action capable of listing and opening every persisted task, including notLoaded tasks.

The hidden-but-intact recovery aspect is also documented in #32508 and #27159.