Skip to content

Codex CLI 0.162.1 on macOS: GPT-6.1 Sol xhigh returns at-capacity on text-only turn; long tasks also lose response stream (Oct 10–12) #53407

Open
Open
Codex CLI 0.162.1 on macOS: GPT-6.1 Sol xhigh returns at-capacity on text-only turn; long tasks also lose response stream (Oct 10–12)#53407
Labels
CLIIssues related to the Codex CLIbugSomething isn't workingconnectivityIssues involving networking or endpoint connectivity problems (disconnections)

Description

@s9008129
s9008129
opened on Oct 12, 2026

Summary

On macOS Apple Silicon, Codex CLI 0.162.1 using the ChatGPT-backed GPT-6.1 Sol (xhigh) model has been unreliable during long-running coding-agent work since approximately 2026-10-10 through 2026-10-12 (UTC+08:00). The client alternates between:

  • Selected model is at capacity. Please try a different model.
  • stream disconnected before completion: An error occurred while processing your request., sometimes followed by repeated reconnect attempts.

This is materially disrupting legitimate long-running coding tasks. The issue is also observed on a text-only request in an existing affected thread, without any tool invocation or task execution.

Environment and diagnostics (sanitized)

  • Codex CLI: 0.162.1, standalone, macOS aarch64.
  • Selected model where the most recent error was observed: GPT-6.1 Sol xhigh.
  • codex doctor --summary: 23 OK, 0 failures, degraded. Installation, configuration parsing, authentication setup, reachability, and WebSocket handshake (HTTP 101) all passed.
  • Local state DB integrity passed; the doctor separately reported two thread inventory/rollout parity warnings (missing rollout rows and duplicates). Their causality is unknown; no reason yet to attribute model capacity failures to those warnings.
  • No proxy environment variables detected by doctor.
  • An ephemeral, new-session, read-only minimal request previously completed with turn.completed; the exact model/provider for that earlier successful request was not established, so it is not presented as proof that the ChatGPT-backed GPT-6.1 Sol endpoint worked.
  • At approximately the same time, a separate Codex window using an Ollama Cloud BYOK provider/model operated normally. This is an imperfect A/B comparison (different provider and model), but argues against complete client or machine failure.

Distinct observation: no tool call necessary

In the previously affected GPT-6.1 Sol xhigh thread, the user issued a text-only diagnostic instruction to answer with SESSION_STREAM_OK, explicitly prohibiting tools, shell commands, GUI operations, file modifications, or resuming the prior task. The response was immediately:

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

This is not explained by a failing project tool or by the contents of a particular command being executed in that turn.

Earlier in the same general incident window, an agent tool was reported Completed, but the subsequent model response failed with stream disconnected before completion and reconnect attempts. Agent state and tool side effects cannot safely be replayed blindly.

Actual versus expected

Actual: Long-running Codex turns repeatedly terminate due to model-capacity errors and/or lost response streams; even a text-only message in the affected thread can fail. The user must interrupt work, preserve state, and recover manually.

Expected: ChatGPT-backed Codex should reliably serve an available selected model, distinguish overload from plan quota exhaustion, and apply safe retry/recovery semantics that preserve completed tool work and long-running task state.

Engineering investigation requested

  1. Correlate the relevant request IDs with backend model admission, server_overloaded/503 results, account/region routing, and fallback/reconnect attempts.
  2. Investigate whether some account/session routes are disproportionately affected, particularly with GPT-6.1 Sol xhigh and long sessions.
  3. Check whether stream disconnected before completion is an alternate downstream manifestation of the capacity problem, or a separate transport issue.
  4. Provide clear status, a durable fix, and safe resume behavior without repeating completed tool operations.

Privacy: Request IDs and original screenshots are available for private OpenAI Support escalation; raw rollouts, account identifiers, repo paths, and sensitive project content are intentionally omitted from this public issue.

Related reports: #53318 (same CLI version, long-running GPT-6.1 Sol failures), #52394 (GPT-6.1 Sol long-task capacity errors), #46208 (account-dependent capacity/stream behavior).

This report documents an observed failure, not a confirmed backend root cause.

Activity

  1. github-actions
    added
    bugSomething isn't working
    CLIIssues related to the Codex CLI
    connectivityIssues involving networking or endpoint connectivity problems (disconnections)
    on Oct 12, 2026

  2. github-actions commented on Oct 12, 2026

    @github-actions
    github-actionsBot
    on Oct 12, 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. s9008129 commented on Oct 13, 2026

    @s9008129
    s9008129
    on Oct 13, 2026 – with ChatGPT Codex Connector
    Author

    Update: another failure on 2026-10-13 (UTC+08:00)

    The same affected local Codex CLI session (GPT-6.1 Sol, xhigh, ChatGPT-backed provider) has encountered another stream disconnected before completion error. The screenshot was captured/reported at approximately 11:00 UTC+08:00; this is an approximate report time, not a verified server-side request timestamp.

    Observed sequence:

    1. An agent tool invocation was initiated.
    2. Codex reported stream disconnected before completion: An error occurred while processing your request.
    3. The tool invocation was separately shown as Completed.
    4. Codex returned to the prompt without a successful completed model turn.
    5. The status bar showed 5h limit: 12% left, so the visible five-hour usage pool was not yet depleted. This does not rule out other service limits.

    Why this matters: The issue is ongoing beyond the originally reported October 10–12 window, and the failure occurred around a tool boundary. Completed is evidence that the individual tool reported finishing, not that the overall agent turn completed or that re-running it is safe.

    A new request ID and original screenshot are available for private Support/engineering correlation; they are not posted publicly to avoid exposing request trace or internal project metadata.

    Request: Please investigate backend correlation of model capacity errors and response-stream disconnects for GPT-6.1 Sol xhigh, including recovery after completed tool calls. No additional reproduction runs are planned due to the disruption and possible duplicated tool side effects.

  4. kriouerlia commented on Oct 13, 2026

    @kriouerlia
    kriouerlia
    on Oct 13, 2026

    Corroborating from a Windows client — same model family, same time window, same alternating symptoms.

    Environment: Windows 10 Pro 22H2 (build 19045) · Codex Desktop (MSIX OpenAI.Codex) 26.930.4958.0 · bundled codex-cli 0.160.0 · ChatGPT Pro (plan_type: "pro") · gpt-6.1-sol (reasoning high), plus gpt-6-astra / gpt-6-sol / gpt-6-luna / gpt-5.6-sol / gpt-5.6-luna / gpt-5.6-terra.

    Window: 2026-10-12 10:20 → 2026-10-13 11:43 (UTC+8), still ongoing. From my local ~/.codex/logs_2.sqlite (table logs, column feedback_log_body):

    • Selected model is at capacity × 59 (10-12: 44, 10-13: 15)
    • unexpected status 503 Service Unavailable × 25 (all on 10-13)
    • Failed to run pre-sampling compact × 17
    • spread across 7 distinct models (astra 20, 6.1-sol 11, luna 10, sol 8, 5.6-luna 5, 5.6-sol 4, 5.6-terra 1)

    Server-side, not transport. Last 60 minutes: unexpected status 503 = 23, while error sending request = 0, is_timeout=true = 0, Falling back from WebSockets to HTTPS transport = 0, websocket ... closed = 0. Independently measured on the same machine: TLS handshake to chatgpt.com:443 20/20 success @ 129 ms, and the wss://chatgpt.com/backend-api/codex/responses Upgrade returned HTTP/1.1 101 and held 62 s without being dropped. (A local proxy DNS misconfiguration was found and fixed before these measurements, so the local path is verifiably healthy.)

    Not quota. The failing requests themselves carry these response headers:

    x-codex-plan-type              = pro
x-codex-primary-used-percent   = 6          # 7-day window, 10080 minutes
x-codex-credits-has-credits    = True
x-codex-credits-balance        = 62381.9437950000
x-codex-secondary-used-percent = 0

    GET /backend-api/wham/usage agrees: allowed: true, limit_reached: false, spend_control.reached: false.

    Request IDs (UTC+8):

    time request id cf-ray
    2026-10-13 11:43:46 ea86d99e-cdb3-4593-b8aa-865448246d7e a49b5a090de8d1d7-ICN
    2026-10-13 10:25:59 e7348878-4aea-4ece-ac9a-024090660d8f a49ae7e13839f255-KHH
    2026-10-13 10:25:15 5f95e6f1-79e6-4408-8f9a-50300f96156a a49ae6b19f6bf24c-KHH

    The egress POPs differ (ICN = Seoul, KHH = Kaohsiung) and the 503s reproduced on both, which may be relevant to the account/region-routing question raised here.

    One nuance worth recording: in my account, very small requests (e.g. a one-line "Reply OK") currently succeed while real workloads fail — so payload size appears to be an aggravating factor on top of the server-side rejection, not the root cause. Full write-up with the same evidence: #53559

  5. davidparks21 commented on Oct 13, 2026

    @davidparks21
    davidparks21
    on Oct 13, 2026

    I'm constantly encountering these issues, both stream disconnected errors and model capacity full. Both are trivial recoveries, prompting, "please resume", but they disrupt long running tasks.

    I'm encountering especially high rate of these errors tonight Oct 12th 8-10pm PDT, 2026, but these issues occur with regular frequency, and are the most challenging aspect of working with codex CLI in my experience.

  6. kriouerlia commented on Oct 13, 2026

    @kriouerlia
    kriouerlia
    on Oct 13, 2026 via email
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

    CLIIssues related to the Codex CLIbugSomething isn't workingconnectivityIssues involving networking or endpoint connectivity problems (disconnections)

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions