[Bug]: A queued follow-up shows as an unlabeled dashed bubble with only Edit and Remove, and no way to send it now #26546

What happened

My follow-up behavior is set to Steer. While a Claude thread was busy (the agent had started two subagents and was waiting on them), I sent a follow-up. It did not steer. Instead it appeared at the end of the timeline as a dashed bubble with only two icons under it: a pencil and an ✕.

Nothing on screen says what this is:

• No "Queued" or "Not sent" label. The only text saying so is screen-reader-only (aria-label="Queued message 1 of 1, not sent" and an sr-only "1 queued" in QueuedRunsControl.tsx).
• No reason why it queued even though I chose Steer.
• No Send now button, so no way to deliver it now.
• No hint of when it will send (after the current run finishes).

It looks like a sent message that is somehow editable. I had to guess that the dashed border means "queued", and I could not find a way to get it delivered short of waiting.

Why it happens (from reading main at 5211acf)

• packages/client-runtime/src/state/threadWorkflows.ts: canSendNow needs activeRun === null, and canPromoteToSteer needs a provider turn with status running. While the run is active but waiting on subagents (or in a startup or wrap-up gap), both are false.
• apps/web/src/components/chat/QueuedRunsControl.tsx renders Send now only when one of them is true. So in that state the row has just Edit and Remove, and no visible label.
• Stopping the run doesn't look like a way out either: the stop path marks queued runs queueHeld: true (Orchestrator.ts, after markStoppedRun), so the message stays parked instead of starting next.

Expected

• A visible label on the bubble, e.g. "Queued, sends when this run finishes".
• When the user's setting is Steer, say why it queued instead ("can't steer while waiting on subagents").
• A way to deliver it now even when Send now can't steer: either keep Send now with a disabled state and tooltip explaining why, or offer "Stop and send".

Steps to reproduce

1. Settings: follow-up behavior Steer (default).
2. In a Claude thread, ask for work that starts subagents (delegated tasks), so the parent run waits on them.
3. While it waits, send a follow-up.
4. The follow-up shows as a dashed bubble with only ✎ and ✕, no label and no Send now.

Environment

• T3 Code desktop 0.1.4-nightly.20261028.3824, Windows 11
• Provider: Claude (Opus 5.5)

Related

• fix(web,mobile): queued messages get a simpler Send now row, no reordering #25846 removed the "Up next · 1 queued" header, which was the last visible text saying the message is queued. Its Send now only shows when it can send, so this state has no text at all.
• feat(web): thread state lives at the end of the timeline, not stacked on the composer #25401 moved queued messages into the timeline as dashed bubbles.
• fix(queued-message): avoid duplicate queued message entries #26355 hides pending queued messages from the timeline (separate bug).
• Discussion Steer: say why a message queued instead of steering #20839 asks Steer to say why a message queued instead of steering.
• Explicit steer is refused with "No running provider turn found" during run startup/completion gaps #23271 / fix(server): queue explicit steer between provider turns #23559 / fix(server,web,mobile): follow-ups sent during setup steer once the turn starts #25749: the "No running provider turn found" refusal in the same gap; once fixed, more messages will land in this unlabeled state.
• fix(web,mobile): held queues show a Queue held state with Resume #21164 adds a "Queue held" state with Resume.

I'll drag in a screenshot after posting.

Filed with Claude Opus 5.5 in Claude Code, running in T3 Code.