[macOS][Chat] Active web-search turn detaches transcript; Stop restores the UI

What issue are you seeing?

During an active web-search response in an ordinary Chat thread in the macOS desktop app, the conversation UI entered a detached state:

• the existing transcript disappeared;
• the conversation became non-scrollable;
• a conversation-not-found-style blank state appeared;
• only Thinking / Searching websites remained visible;
• the image attachment action failed with an unknown-error message;
• pressing Stop immediately restored the transcript and composer;
• image attachment became available again after the turn ended;
• the final answer appeared at completion instead of rendering incrementally.

The same synchronized conversation on chatgpt.com served as a control: its transcript remained visible and scrollable, web-search progress remained attached to the conversation, and the image attachment control remained usable during the active turn.

What steps can reproduce the bug?

1. Open an existing ordinary Chat conversation in the macOS desktop app.
2. Open the same synchronized conversation on chatgpt.com for comparison.
3. In the desktop app, submit a prompt that triggers a relatively long web-search response.
4. While the response is active, observe the transcript and scrolling state.
5. Try to attach an image from the desktop composer.
6. If the detached state appears, press Stop.

Observed in the macOS app:

• tool-status text remained visible while the persisted transcript disappeared;
• the conversation could not be scrolled;
• image attachment produced an unknown-error state;
• Stop restored the transcript and composer without restarting the app;
• the completed answer appeared all at once.

Observed in the Web control:

• the transcript stayed visible and scrollable during the active turn;
• per-site web-search progress remained attached to the conversation;
• image attachment remained available.

What is the expected behavior?

• Starting an active turn must not detach or hide the persisted transcript.
• The transcript, active-turn status, composer, and attachment capability should remain mutually consistent.
• If attachments are intentionally unsupported during an active turn, the UI should state that explicitly instead of showing an unknown error.
• Stop should not be required to recover the conversation renderer.
• Incremental answer and tool progress should remain attached to the same visible conversation.

Additional information

• macOS desktop app: 26.901.20858 (build 7658)
• Desktop OS: Darwin 27.0.0 arm64
• Web control browser: Google Chrome 152.0.7977.77
• Date observed: 2026-09-04 KST

#37572 is related but narrower: it reports that the macOS Chat composer cannot send another message while a response is generating. This report covers transcript disappearance, loss of scrolling, attachment failure, completion-only rendering, and recovery via Stop. #24287 describes a similar active-turn detachment in Codex Desktop, but this report does not claim a shared root cause.

The report names no files, tests, or entry points. Reproduce a long web-search turn in the macOS desktop app and compare it with the web control, then trace the transcript, active-turn, composer, attachment, and streaming states; done means the transcript stays visible and scrollable, progress remains attached, and Stop is not needed for recovery.