[macOS] Existing tool/image chats fail after HTTP 200 across two app builds; same-core minimal probe succeeds #53127

What version of the Codex App are you using (From “About Codex” dialog)?

Verified from the installed macOS app bundle:

• Initial failures: 26.1007.21159 (build 20052)
• Failures after the app update/restart: 26.1007.30912 (build 20156)

The bundled core is codex-cli 0.162.0-alpha.17.2 in both observations. The current core version was also checked by running the bundled binary with --version.

What subscription do you have?

ChatGPT Pro (the affected Responses request headers reported x-codex-plan-type: pro; no raw headers are attached).

What platform is your computer?

macOS 27.0.1 (26A434), Apple silicon / arm64. Local execution in the ChatGPT-branded desktop app (Codex runtime).

What issue are you seeing?

Two independent existing local conversations, one involving image composition and one involving presentation review/editing, repeatedly fail to continue. The UI reaches “Reconnecting 5/5” and reports:

stream disconnected before completion: An error occurred while processing your request. You can retry your request, or contact us through our help center at help.openai.com if the error persists. Please include the request ID ... in your message.

This is an observed reliability failure, not a claim that the root cause is proven.

The same endpoint/model is involved: https://chatgpt.com/backend-api/codex/responses, gpt-6.1-sol, reasoning effort xhigh.

Correlated failures on 2026-10-11 (UTC+8)

Affected local session IDs:

• Image workflow: 01a12ad0-63a0-70b2-b1c1-e0b3933cf5cd
• Presentation workflow: 01a12af9-a295-7b91-8c0c-4e5f2c6e98ea

The presentation terminal turn is 01a12b49-5beb-79b1-8e9c-804c60764110; the post-update image terminal turn is 01a12b49-5bc9-77a1-b54b-57d725fde0be.

Exact transport observations after the update

For the presentation failure:

1. 22:06:45–22:07:16: five retries report websocket closed by server before response.completed.
2. 22:07:28: codex_core::client logs falling back to HTTP.
3. Five further HTTP attempts report the generic processing error above.
4. The final codex_http_client::client record at 22:09:28 has status=200 OK, version=HTTP/1.1, the Responses endpoint, and x-oai-request-id=b2f45aa4-0fcb-4f21-a4e3-3d5d291b84f6.
5. The next terminal turn record at 22:09:29 reports that exact request ID and the processing error.

The post-update image continuation also encountered Broken pipe (os error 32) and a WebSocket close, fell back to HTTP at 22:09:07, then failed after HTTP processing-error retries.

HTTP 200 here confirms received response headers, not a completed response stream. The raw SSE error event was not captured, so the precise upstream error code is unknown. Please correlate the request IDs server-side.

Request size / context comparison

• Presentation failure: raw request body 18,808,335 bytes; zstd-compressed body about 13,708,670 bytes.
• Initial image failures: compressed request bodies grew from about 39.4 MB to 54.2 MB (decimal MB).
• Both histories contain a recorded context-compaction event before these failures.
• Image history's last recorded successful model input before the initial failures was about 249,726 tokens against a reported 760,000-token context window.
• The latest inspected presentation input record was about 302,676 tokens against the same reported window, but it belongs to the subsequently resumed work, not necessarily the exact failed request.

These observations do not establish a context-size threshold or a text-context overflow. In particular, the smaller presentation request also failed, so the largest image payload cannot by itself explain all incidents.

What steps can reproduce the bug?

Observed sequence (intermittent; no public deterministic reproducer yet):

1. Work in an existing local desktop conversation with multiple tool calls and inspected/rendered images.
2. Complete and save a meaningful artifact.
3. Send a short follow-up requesting continuation or a text deliverable based on the saved artifact.
4. Observe retries, WebSocket-to-HTTP fallback on the updated build, and terminal processing-error failure.
5. Repeating continuation after the app update/restart can fail in both independent histories.

Redacted examples of the follow-up requests:

• “Has the image generation finished?”
• “Write a roughly ten-minute narration based on the saved presentation.”
• “Continue.”

Same-machine minimal control, actually executed: using the currently bundled core, the existing user configuration, the same model and reasoning effort, and the current network:

<bundled-codex> exec --ephemeral --skip-git-repo-check --json --color never \
  --sandbox read-only --model gpt-6.1-sol \
  -c 'model_reasoning_effort="xhigh"' \
  'Diagnostic connectivity probe only. Reply with exactly STREAM_PROBE_OK. Do not use tools, read files, run commands, or modify anything.'

The probe returned STREAM_PROBE_OK and a turn.completed event (34,827 input tokens; 8 output tokens). The contemporaneous diagnostic desktop conversation also continued without response-retry warnings.

This single successful control does not rule out intermittent network faults or reproduce the larger existing conversation's input. It does show that the same core/account/model/network is not failing on every request.

What is the expected behavior?

Existing conversations should remain continuable, with completed files/actions preserved. When a stream fails, please expose an actionable failure classification and provide a supported in-place recovery path. A generic “Reconnecting” label should not obscure the distinction between a transport interruption and an upstream processing failure.

Additional information

Read-only local checks found no custom model-provider/base-URL override, no per-project Codex configuration override in the two affected workspaces, and no HTTP/HTTPS/ALL_PROXY environment variables in the diagnostic process. At inspection time macOS explicit HTTP/HTTPS/SOCKS/PAC proxy settings were disabled. A VPN client/core process was running; its historical traffic path was not reconstructed, and no controlled alternative-network test was performed. Network involvement is therefore not completely excluded.

No local network/model/global configuration was changed, no application files were patched, and the affected conversations were not replayed by the diagnostic probe. The presentation conversation had already been resumed by the user; this investigation did not send messages or repeat external actions in it.

Completed image files survived the failed turns and were independently verified. This matters because retries of a task can risk repeating already-completed external actions.

Requested investigation:

1. Correlate the four request IDs and determine the actual upstream processing-error code and failing component.
2. Determine whether existing multimodal/tool conversation state, the shared core version, or WebSocket/HTTP recovery contributes.
3. Identify a supported recovery/workaround that preserves existing history and work; clarify whether a core/app fix or backend remediation is required.
4. Improve error reporting so transport failures and semantic processing errors are distinguishable.

I searched existing reports. Possibly related: #52814 and #52731. They share symptoms; a shared root cause is not established. This report adds cross-workflow/cross-build evidence, precise HTTP/request-ID correlation, smaller-payload failure, and an executed same-core control. Please consolidate if appropriate.

No screenshots, business documents, personal photos, raw transcripts, raw response headers, auth credentials, account email addresses, or local usernames/paths are included.