[Windows Desktop] Pro chat turn completes with no assistant message or error

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

• #37879

Powered by Codex Action

The automated duplicate check suggested #37879. After reviewing the related chain, #37879 and #32389 appear related at the “successful empty completion” symptom level.

However, this reproduction differs materially: it occurs in a small, isolated ChatGPT chat with no tools; it is specific to the Pro selector; and a non-Pro control succeeds in the same chat, app session, and network. The client-visible conversation state reports the Pro turn as completed with error=null but contains only the user item.

#27352 and #26860 appear more distant because they involve progress-message finalization and Amazon Bedrock respectively. Please merge only if internal traces confirm the same underlying cause.

Update — 2026-08-20

The issue reproduced again on ChatGPT Desktop version 26.814.41957 (package 26.814.5517.0).

A minimal Pro canary in a new empty chat at 2026-08-20T06:30:16.025Z returned to idle after approximately five seconds. After more than five minutes, the persisted turn remained completed with error=null and contained only the user message, with no assistant item.

Unlike the previous throttled window, no conversation-list HTTP 429 or local network error was recorded around this reproduction.

Feedback ID:
no-active-thread-01a01de9-c78b-7083-9725-c987bc0c597d

Related cross-client observation: the same account is currently also unable to use Pro for sending messages on both the web app and the iPhone app. I do not have equivalent turn-level diagnostics from those clients, so I am reporting this only as related context and am not asserting that all three surfaces share the same underlying failure.

Update — 2026-08-21:

Reproduced once on Windows Desktop app version 26.818.22352, package 26.818.2872.0.

• Conversation: 6a88018a-5b1c-83eb-85de-007a05d00c1a
• Turn: 45a7e977-e8d1-4ce3-8593-4b5868414c94
• Timestamp: 2026-08-21T07:43:05.527Z
• Feedback ID: no-active-thread-01a02351-c6fb-7312-9216-7b097be783c3

The Pro turn is persisted as completed with error=null, but contains only the user message and no assistant item after more than five minutes. The direct conversation refetch returned HTTP 200. No contemporaneous 403, 429, 5xx, or general network error was observed. No retry or model switch was performed.

Separate cross-client observation: the account UI reports an active Pro subscription, but Pro remains absent from the selectable model options on ChatGPT web and iPhone. Causal relationship to the Desktop silent completion is unknown.

Update — 2026-08-25

The issue has recurred on Windows Desktop build 26.818.61809.

Pro worked normally across multiple real tasks for several hours earlier today. Silent completions then resumed in an existing long-running chat and were subsequently reproduced with a minimal prompt in a completely new, non-project chat.

The new controlled turn persisted as:

• status: completed
• error: null
• user item: present
• assistant item: absent

New in-app feedback with session logs:

Feedback ID: no-active-thread-01a03a48-d25f-79e1-b4be-e77cd7601895

The private conversation and turn identifiers have been provided to OpenAI Support under Case 13124195.

Update — Aug 27, 2026: reproduced again on Desktop 26.820.71523

After updating to the newly released Windows Desktop build 26.820.71523 (Powered by Codex & OWL), I ran another controlled Pro canary in a completely new, non-project chat.

Conversation ID: 6a8fd7ad-3d10-83ed-a35f-e60ca9b6e90c
Observed timestamp: approximately 2026-08-27T06:22:55Z
Feedback ID: no-active-thread-01a041f0-f956-7130-98bb-64259aa26cf9

Prompt:

DIAG-PRO-20260827-C2 — Responde únicamente: OK-PRO-20260827-C2

Result: no assistant response was produced; the chat remained silent.

The issue therefore still reproduces after the Aug 27 Desktop update.

There is also new diagnostic evidence in the current session logs that differs from the original Aug 14 reproduction.

The logs explicitly confirm:

release=26.820.71523

and, around the reproduction, contain account/authentication warnings including:

desktop_fetch_auth_401 hadToken=true ... tokenSource=cached willRetry=true

followed by:

status=401

{"detail":"Must use workspace account for this operation"}

For example, the latter occurs at approximately 2026-08-27T06:22:47.240Z, only seconds before the observed silent Pro canary.

I am not asserting that these 401/account-routing warnings are the root cause, but they may be relevant. This is different from the original Aug 14 controlled reproduction documented in this issue, where local diagnostics found no correlated authentication/HTTP 401/403 errors.

I could not identify a Turn ID with enough confidence from the local logs, so I am deliberately not guessing one.

Please correlate this reproduction with the uploaded feedback/session logs using the Feedback ID above.

Update — Aug 27, 2026: reproduced again on newer Desktop build 26.820.80927

A second Windows Desktop build became available today. I updated the application, fully relaunched it, and performed one controlled Pro canary in a new chat.

Desktop version: 26.820.80927
Powered by Codex & OWL
Release: Aug 27, 2026
Conversation ID: 6a90abd5-4a48-83ed-8816-b48cefbd26b5
Observed time: approximately 2026-08-27T21:27:55Z
Feedback ID: no-active-thread-01a04522-eb48-7701-8e20-dcfa43c6f370

Controlled prompt:

DIAG-PRO-20260827-D1 — Responde únicamente: OK-PRO-20260827-D1

Result: no assistant response was produced; the chat remained silent.

Local log review provides the following additional anchors:

• The logs explicitly confirm release=26.820.80927.
• The affected conversation was refetched at 2026-08-27T21:27:52.276Z.
• That refetch completed at 2026-08-27T21:27:52.661Z with asyncStatus=null and statusAfter=idle.
• No correlated 401, 403, 429, or 5xx appears in that immediate affected-conversation window.
• The first subsequent desktop_fetch_auth_401 / Must use workspace account for this operation warning appears only after the client had already switched to a different conversation at 2026-08-27T21:28:00.954Z.
• I therefore do not consider that 401 directly correlated with this Pro canary.
• I could not identify a Turn ID that can be attributed to this canary with sufficient confidence, so I am deliberately not guessing one.

The feedback bundle was successfully uploaded with session logs. The local upload completed with errorCode=null at 2026-08-27T21:32:10.284Z.

Local feedback-upload request ID:

c025bf81-c7bd-430b-b33f-6406d46473e2

Earlier today, the same controlled Pro silent-completion behavior was reproduced on Desktop build 26.820.71523.

The issue therefore remains reproducible across two separate Aug 27 Desktop builds, including the newer 26.820.80927 release.

Concurrent cross-client observation: Pro also remains unavailable as a selectable option on chatgpt.com and in the iPhone app for the same active Pro account. This has persisted across the recent Desktop builds. I am reporting it as a potentially relevant account/model-availability symptom, not as evidence that the web/iPhone behavior has the same failure mechanism as the Windows Desktop silent completion.

Please correlate this reproduction with Feedback ID no-active-thread-01a04522-eb48-7701-8e20-dcfa43c6f370 and the previous evidence in this issue.