[ChatGPT Work] “Error in message stream” leaves external action outcome ambiguous

Summary

Two attempts to confirm an approved email action in ChatGPT Work ended with Error in message stream. The conversation did not expose whether the external Gmail mutation had started, failed, or completed. A blind retry could therefore have sent a duplicate message.

Read-only reconciliation against Gmail Sent, Gmail drafts, and the authoritative GitHub checkpoint established that neither attempt had produced a persistent side effect. After an explicit retry instruction, exactly one email was sent and its durable checkpoint was recorded.

A related recovery later found that an automation create action had completed even though the exhausted conversation exposed no completion response or durable receipt. A replacement conversation created an equivalent second watch because the first action was not discoverable from the visible conversational state.

These incidents show that assistant-response delivery and external-action outcome need separate, durable status. They do not establish where either failure occurred internally.

Environment

• ChatGPT Work on the web
• Connected Gmail
• Connected task automations
• GitHub-backed source-of-truth checkpoints
• Externally mutating actions requiring explicit user approval
• Observed: 29 August 2026

Primary incident steps

1. Prepare an email to approved recipients and wait for explicit user confirmation.
2. Receive the user's confirmation to send.
3. Observe Error in message stream.
4. Repeat the confirmation and observe the same error again.
5. Observe that the conversation provides no durable action status for either attempt.
6. Reconcile Gmail Sent, Gmail drafts, and the authoritative GitHub checkpoint read-only.
7. Establish that no matching email or checkpoint exists.
8. Receive an explicit retry instruction.
9. Send exactly one email and record the delivery checkpoint.

Secondary evidence

In a separate exhausted conversation, the final visible instruction requested creation of a reply-monitoring automation. The visible conversation contained no success response or durable receipt. Recovery work therefore treated the instruction as unhandled and created an equivalent watch.

A later private automation inventory showed that the original create action had succeeded. The duplicate was paused and the earlier task retained. No duplicate notification had been emitted.

Actual result

• A response-stream failure left the external email outcome ambiguous.
• The user could not determine from the conversation whether dispatch had occurred.
• Safe retry required manual provider and source-of-truth reconciliation.
• A completed automation create operation was not recoverable from visible conversation state.
• The replacement workflow did not detect the semantically equivalent existing automation before creating another.

The incidents demonstrate a recoverability and idempotency gap. They do not establish that every message-stream failure has the same action outcome.

Expected result

Every approved external mutation should have a durable operation record independent of assistant-response delivery.

The user and a replacement conversation should be able to determine whether the operation is:

• approved but not started;
• started;
• acknowledged by the provider;
• durably checkpointed;
• failed before any side effect;
• partially completed across systems; or
• indeterminate and awaiting reconciliation.

Retry should be idempotent when supported. Otherwise, the product should block retry until provider state has been reconciled or the user deliberately authorizes a new operation.

User impact

• Blind retry can duplicate emails, invitations, automations, or provider changes.
• Avoiding duplication requires manual inspection of every affected system.
• Multi-system actions may complete at the provider but fail before their durable checkpoint.
• Replacement conversations can repeat a completed action that has no visible receipt.
• Users cannot confidently distinguish tool outcome from response-generation failure.

Requested product behavior

• Assign every approved external action a stable operation identifier and idempotency key.
• Persist the action lifecycle independently of the assistant message stream.
• Record provider acknowledgement separately from assistant-response completion.
• Show the durable receipt after reconnecting or opening a replacement conversation.
• Retrieve outstanding, completed, and indeterminate operations before retrying.
• Apply semantic duplicate detection to create operations such as equivalent scheduled or event-driven watches.
• Prevent duplicate execution of a provider-acknowledged operation.
• Require read-only reconciliation when an operation remains indeterminate.
• Support convergence receipts for actions that require both provider mutation and source-of-truth checkpointing.
• Keep receipts privacy-minimized and avoid exposing credentials or unnecessary provider content.

Acceptance criteria

• A message-stream failure never leaves an external mutation with only conversational status.
• The user can inspect the stable operation ID, provider acknowledgement, and checkpoint state.
• Replaying the same approved operation is idempotent or explicitly blocked pending reconciliation.
• A replacement conversation can retrieve the receipt without relying on summarized memory.
• A provider-acknowledged action cannot be repeated merely because response generation failed.
• Equivalent automation creates are detected before mutation and surfaced for deliberate reuse or replacement.
• Partial multi-system completion is shown explicitly and can be reconciled safely.
• Automated tests cover failure before dispatch, during dispatch, after provider acknowledgement, before checkpoint persistence, and after action completion but before response delivery.

Related issues

• #38474 reports Gmail delivery succeeding despite an error result, causing duplicate email on retry. This report includes the complementary no-side-effect case and requires a durable status that does not infer outcome from the response stream.
• #39566 reports automation creation returning no authoritative result when no matching automation persisted. This report adds a completed create that remained hidden and caused a semantically equivalent duplicate.
• #40512 reports completed assistant output missing from the live projection. This report focuses on the resulting safety problem for non-idempotent external actions and cross-system convergence.

Interim workaround

After any response-stream failure associated with an external mutation:

1. do not retry immediately;
2. inspect the target provider read-only;
3. inspect the authoritative durable checkpoint;
4. classify the operation as completed, absent, or indeterminate;
5. retry only when absence is established or an idempotent retry is guaranteed.

Privacy

No email contents, recipient addresses, account email, provider message IDs, automation identifiers, private repository links, credentials, or screenshots are included.

No implementation files, tests, or entry points are named. Start by reviewing the related issues and mapping the requested operation lifecycle across provider acknowledgement, durable checkpoints, response delivery, and replacement conversations; done means the acceptance criteria are covered, including safe retry, receipts, reconciliation, and duplicate prevention.