Repository navigation
[Bug]: A queued follow-up shows as an unlabeled dashed bubble with only Edit and Remove, and no way to send it now #26546
Description
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 ansr-only"1 queued" inQueuedRunsControl.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:canSendNowneedsactiveRun === null, andcanPromoteToSteerneeds a provider turn with statusrunning. 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.tsxrenders 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, aftermarkStoppedRun), 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
- Settings: follow-up behavior Steer (default).
- In a Claude thread, ask for work that starts subagents (delegated tasks), so the parent run waits on them.
- While it waits, send a follow-up.
- 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): steers sent before a turn starts join it once it does #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.
Activity
bmdalex commentedon Nov 1, 2026
Additional observation on macOS, 1 November 2026
Send now did not deliver the user's queued messages immediately. The screenshot shows two
/goal clearmessages as dashed bubbles, each with only pencil and X controls. No Send now control or explanation of the queue state is visible. The composer still shows a red Stop button although the latest visible answer and goal indicator look complete.The screenshot shows the queue presentation, not the Send now click, so it does not establish which action failed.
Saved run history shows that both messages eventually started:
/goal clear/goal clearBoth completed later. The queue was empty when checked. It was not edited, cancelled, or promoted during this investigation.
Expected: Send now delivers the message immediately when offered. If immediate delivery is unavailable, the UI explains that the message is queued, why, and how to continue.
Version: running T3 server
0.1.7-nightly.20261101.4035, macOS arm64. The exact client build and affected browser/app surface were not independently established. Root cause and frequency are unconfirmed.Screenshot attachment is not yet included because browser upload automation is unavailable.
kaijiabo commentedon Nov 13, 2026
Note
🤖 Claude Opus 5.5 responding on behalf of Kai
On 0.1.7 with Claude, the most common way into this state is a wake turn: a turn Claude starts on its own when a background task or a recurring CronCreate check reports back. T3 has no provider turn for it, so
canSendNowandcanPromoteToSteerare both false until Claude reaches the user's run. On a thread with a live watcher, that happens every 1–3 minutes.Measured on one thread (provider events log, Nov 13 UTC):
system init) at 03:18:28, 03:20:30, 03:22:32, 03:23:08 and 03:24:45. Several followed directly fromtask_notificationorbackground_tasks_changedevents.startinguntil about 03:27, with no Send now button.t3_queue promote_to_steerfailed twice during that window, at about 03:26 and 03:27, withNo running provider turn found for active run …. The same call succeeded at about 03:28, after Claude reached the run.system init, on a thread of about 4,700 items. The delay comes entirely from waiting behind wake turns.t3_thread_send mode:"steer"returnedhas no running turn that can be steeredwhile the thread showed as running.mode:"restart"returnedClaude cannot redirect an active run. Stop it first.Stop can hit the wrong run. At 03:23:37 the user pressed Stop to make their queued message go next. The turn shown as running had already finished at 03:23:28, so Stop cancelled the next queued run instead.
Repro:
promote_to_steerfails withNo running provider turn found.Expected: a wake turn accepts a steer like any other Claude turn. If it can't, Send now should stay visible and interrupt the wake turn.
This may be what #32134 hit. #33272 is the same race seen from
delegate_task.Our workaround is to slow checks to every 10 minutes and remove streaming watchers. That makes the blocked windows rarer, but it doesn't remove them.