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

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

• #32545
• #32973

Powered by Codex Action

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

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.

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.

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.

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.

I implemented and production-probed a structural fix on current upstream main:

Branch: https://github.com/adpena/codex/tree/fix/explicit-compaction-mode
Fork draft PR: https://github.com/adpena/codex/pull/1
Upstream compare: https://github.com/openai/codex/compare/main...adpena:codex:fix/explicit-compaction-mode
Commits: 2c5021c36, a0ad9a356

The change introduces a typed CompactionMode::{Auto, Local, Remote} authority and threads it through config, config locking, manual and automatic dispatch, app-server config reads, generated schemas, and tests. auto preserves existing behavior; local selects the existing local summarization path without spoofing provider identity.

End-to-end production probe using the real openai provider plus compaction_mode=local passed: first exact response, manual compaction, durable persisted compacted and context_compacted records, then an exact post-compaction response. Production timings were 23.292s first turn, 5.156s compaction, 10.102s second turn, 39.628s total.

The release app-server was built with zero warnings. Cold build: 111m27s, peak tree RSS ~9.49 GiB, peak private ~10.50 GiB. Warm build: 63m17s. Release binary: 348,788,224 bytes. After the production probe the service used 677,220,352 bytes RSS / 622,223,360 bytes private, 46 threads, 494 handles; that growth remains a profiling target.

The branch is rebased conflict-free onto current main. The connected GitHub integration returned 403 Resource not accessible by integration when creating the upstream draft PR, and the local gh token is expired. The fork draft PR and upstream compare above are the current review entrypoints.

GitHub CLI authentication has now been refreshed and normal repository/issue access works, but opening the upstream draft PR from the existing fork branch still fails with: \GraphQL: adpena does not have the correct permissions to execute CreatePullRequest (createPullRequest)\. The tested implementation remains available at the fork draft PR https://github.com/adpena/codex/pull/1 and upstream compare https://github.com/openai/codex/compare/main...adpena:codex:fix/explicit-compaction-mode. A maintainer can open/import the branch or grant the integration permission needed to create the upstream PR.