Send queued messages together: a "Steer all" action and a batched queue mode

[Guria]

A thread's queue drains one message per turn (#6885), and thread.steerQueuedMessage steers only the oldest queued message. That's fine for unrelated follow-ups. When the queued messages belong together, the agent handles them separately: it re-plans after each one, and it can act on the first before it sees a later one that changes the picture.

I hit this in two ways:

• As the operator. During a long turn I queue notes as they come to me, for example one message per review point while I read the diff. Four notes become four turns.
• With threads working together. Worker threads report to a coordinating thread with t3_thread_send. While the coordinator is busy, each report lands in its queue (mode: "queue", or "auto" before the turn is steerable), and again each one gets its own turn.

I'd like two ways to deliver the queue together. Both serve both cases.

1. "Steer all" action

Joins every queued message into one message and steers it into the running turn. The queue is empty afterwards.

• Operator: the agent heads the wrong way while I have three corrections queued. Today I either promote them one by one, which gives three steers each landing mid-reasoning, or I copy them into the composer by hand. "Steer all" is one action.
• Collaborating threads: I see several worker reports waiting in the coordinator's queue and want it to use them now, in a single update. The coordinating agent could do the same itself.

Places it would go: a button by the queue list, a keybinding next to thread.steerQueuedMessage, the mobile queue sheet, and an MCP tool alongside t3_queue_promote_to_steer. Available only when the provider supports steering, like the existing steer.

2. Batched queue mode

When a turn ends, the next turn gets everything queued so far as one message instead of only the first.

• Operator: I keep writing review points during the turn without merging them by hand, and the agent gets them in one turn where it can weigh them against each other. [Feature]: Quote part of an assistant message and batch replies into one turn #6974 makes the same argument for quoted replies: "One turn where the agent sees all four objections together beats four turns where it re-plans after each one."
• Collaborating threads: the coordinator waits on workers that finish at different times. Whatever arrived during its current turn reaches it in one next turn.

This has to be a server-side, per-thread option, not part of Follow-up behavior. That setting applies per client and decides how my own messages enter the queue. Batching decides how the queue leaves, whoever filled it, and messages from other threads never go through a client. Per-thread fits because only some threads need it. It could also be settable at t3_thread_launch, so a coordinator starts with it on.

Open questions

• Join format: plain separator, or a header per message showing its source (me or a sending thread)? Attachments merged into the combined message?
• Per-thread setting, environment default, or both?
• Is the mode worth adding, or are "Steer all" plus a "send all as next turn" queue action enough?

Related: #6885, #11912, #6974.

---

Drafted with AI assistance: Claude Opus 5.5 (claude-opus-5-5) via Claude Code in T3 Code.

[Dwite]

I have the same problem as the operator: several queued notes that are one request.

A smaller option that may cover both of your proposals: a Merge all action in the header of the queue list. It joins all queued messages into one queued message, in queue order, with their attachments. The result stays in the queue as a normal message. Nothing is sent.

The existing actions then do the rest:

• Merge, then Steer: the same result as "Steer all".
• Merge, then wait: everything goes as one next turn.
• Merge, then the pencil: I can clean up the text first.

This needs no new mode and no new setting. I think it answers your third open question.

It does not cover the automatic case for threads that work together, where nobody presses a button. An MCP tool next to t3_queue_edit could help there: the coordinator merges its own queue before the next turn.

[shcpj]

Adding a concrete user experience from Windows desktop with a long-running Codex coordinator and a separate Claude thread.

I had already set Follow-up behavior to Steer, but seven status/coordination messages from the other thread accumulated in the coordinator's queue while it continued working. Inspecting the sender calls showed explicit t3_thread_send calls with mode: "queue"; the tool reported delivery: "queued". These were coordination updates needed during the current turn, not independent future tasks.

The workaround was to read them with t3_queue_list / t3_queue_read, then promote all seven individually using t3_queue_promote_to_steer. The queue was empty afterward. We also instructed the sender to use auto/steer going forward.

This supports the proposed Steer all action. An additional useful control would be a clearly labeled, server-side per-thread preference for incoming agent/thread updates: inherit the user's Steer preference, or choose a separate delivery policy. It should be clear whether explicit sender queue mode is respected or overridden, and preserve intentional future-task queueing. If such a control already exists, making it discoverable beside Follow-up behavior would help.

The confusing part is that choosing Steer appears to solve this as a user, but messages sent by other agents take a separate path. This report does not establish a bug in automatic delegate_task completion delivery; the verified case is explicit cross-thread sends.

Posted with the user's authorization by their coding assistant. No private project data or logs attached.