Skip to content

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

Open
Open
Codex Desktop: remote-compaction capacity error terminalizes one persistent goal while other tasks remain healthy#33171
Labels
appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesbugSomething isn't workingconnectivityIssues involving networking or endpoint connectivity problems (disconnections)contextIssues related to context management (including compaction)

Description

@adpena
adpena
opened on Jul 14, 2026

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

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

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    contextIssues related to context management (including compaction)
    app-serverIssues involving app server protocol or interfaces
    connectivityIssues involving networking or endpoint connectivity problems (disconnections)
    on Jul 14, 2026

  2. github-actions commented on Jul 14, 2026

    @github-actions
    github-actionsbot
    on Jul 14, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. adpena commented on Jul 14, 2026

    @adpena
    adpena
    on Jul 14, 2026 – with ChatGPT Codex Connector
    ContributorAuthor

    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:

  4. adpena commented on Jul 14, 2026

    @adpena
    adpena
    on Jul 14, 2026 – with ChatGPT Codex Connector
    ContributorAuthor

    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.

  5. adpena commented on Jul 14, 2026

    @adpena
    adpena
    on Jul 14, 2026 – with ChatGPT Codex Connector
    ContributorAuthor

    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.

  6. adpena commented on Jul 15, 2026

    @adpena
    adpena
    on Jul 15, 2026 – with ChatGPT Codex Connector
    ContributorAuthor

    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.

  7. the1337moderator commented on Jul 15, 2026

    @the1337moderator
    the1337moderator
    on Jul 15, 2026 – with ChatGPT Codex Connector

    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.

  8. adpena commented on Jul 15, 2026

    @adpena
    adpena
    on Jul 15, 2026 – with ChatGPT Codex Connector
    ContributorAuthor

    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: 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.

  9. adpena commented on Jul 17, 2026

    @adpena
    adpena
    on Jul 17, 2026
    ContributorAuthor

    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 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.

  10. tcreevan commented on Sep 17, 2026

    @tcreevan
    tcreevan
    on Sep 17, 2026

    Comment on issue #33171

    I can reproduce the same post-compaction Goal recovery failure in the VS Code Codex extension, not only Codex Desktop.

Environment:
- Codex extension: openai.chatgpt 26.908.40401
- VS Code: 1.138.0
- Windows 11 Enterprise: Microsoft Windows NT 10.0.26100.0 x64
- Selected foreground model: GPT-5.6 Sol

Observed sequence:
1. A persistent /goal was pursuing normally.
2. Automatic context compaction occurred.
3. The continuation displayed: "Selected model is at capacity. Please try a different model."
4. The /goal changed to stalled and did not recover automatically.
5. Clicking Resume manually restored the same goal and work continued.

This has occurred repeatedly. The visible capacity message was not preserved in Codex.log. During the same interval, the extension logged repeated "Received ... for unknown conversation", "Conversation state not found", and then "maybe_resume_started" events. I can provide a sanitized excerpt or the affected identifiers privately if useful.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesbugSomething isn't workingconnectivityIssues involving networking or endpoint connectivity problems (disconnections)contextIssues related to context management (including compaction)

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions