t3_thread_send agents pick mode "queue" for running threads since the tool copy cut, so messages queue instead of steering

查找工具 t3_thread_send 的说明和 OrchestratorMcpThreadSendInput.mode schema；issue 未提供它们的文件路径。阅读当前副本和 schema，然后更新内容，说明 auto 是通常的默认值，而 queue 用于有意分开的后续轮次。当两处说明都引导代理使用 auto，除非明确打算使用 queue 时，即为完成。

What happened

The t3 orchestrator in nightly seems to almost always send messages as queued messages instead of mid session steers. This used to be the other way around.

An orchestrating agent thread used t3_thread_send to message another thread that was mid-turn. The message showed up in the target thread's queue instead of being steered into the running turn, so the user had to promote it to a steer manually. The user reports this started a few days ago on nightly and does not depend on the provider.

Diagnosis

The server's delivery logic is working as designed. The agent explicitly passed mode: "queue":

mcp__t3-code__t3_thread_send { threadId: "ccd69e8e-…", mode: "queue", message: "FYI from another thread (no action needed): …" }
→ { runId: "…:ordinal:4", status: "queued", delivery: "queued" }

With mode omitted or set to "auto", ThreadManagementService.sendToThread would have picked steer_active. The target's run 3 was running and its provider turn was running (it was in the middle of a long tool call), so latestSteerableRun() would have matched.

What changed is the agent's choice of mode. In this user's history, every t3_thread_send call before 2026-10-25 passed mode: "auto" (11/11, which resulted in started or steered). The first call after updating passed mode: "queue". The likely trigger is #24850 ("cut T3's agent instructions and tool copy by 60%", 2026-10-25), which rewrote the t3_thread_send description:

• Before: "…mode='auto' starts an idle thread, steers a fully active turn, or queues behind a turn that is not yet steerable. Use queue for a separate follow-up turn, steer for an in-flight update, or restart to interrupt-and-restart the active turn. …"
• After (still on main): "mode:'auto' starts an idle thread, steers a running turn, or queues. queue: new turn. steer: mid-turn update. restart: interrupt and restart. …"

The new copy lists the four modes as equal options. Neither the description nor the schema (OrchestratorMcpThreadSendInput.mode is a bare optional literal with no description) tells the agent that auto is the default and the normal choice. For an informational "no action needed" message, queue: new turn looks like a reasonable pick to the model. But that delays the message until the target's current turn ends and adds a whole extra turn just to read an FYI.

The evidence is thin: there is one call after the change, and mode selection is a model decision rather than a deterministic code path. Still, the switch from consistent auto to queue lines up with the copy change.

Suggested direction: state in the tool description and/or the mode schema description that auto is the default and should normally be omitted or used, and that queue is only for deliberately separate follow-up turns.

Steps to reproduce

1. On nightly 0.1.3-nightly.20261025.3682, start a long-running turn in thread B (for example, a tool call that takes a minute or more).
2. In thread A (Claude), ask the agent to send thread B an informational update via t3_thread_send.
3. Look at the tool call input: the agent may pass mode: "queue". The message lands in B's queue (delivery: "queued") instead of being steered into the running turn.
4. Compare with a build from before #24850, where agents in the same situation passed mode: "auto" and the message was steered.

This is not deterministic, because it depends on which mode the model picks.

Version

0.1.3-nightly.20261025.3682 (desktop app, T3 Code (Nightly), local server). The triage CLI was 0.1.2.

Environment

macOS 26 (Darwin 25.6.0, arm64), Node v26.12.1. Desktop Nightly app against its local server. The orchestrator thread runs Claude; the user reports the same behavior regardless of provider.

Evidence

# Target thread ccd69e8e-… (UTC), from statev2.sqlite projections
run 3  running  10:15:13 → 10:17:53   (provider turn 3 running throughout)
10:17:16  t3_thread_send from thread 9403dd35-… with mode:"queue" → new run 4, status queued, delivery "queued"
10:17:44  user promotes queued message → run 4 cancelled, turn item inputIntent "promoted_queued_to_steer" in run 3

# t3_thread_send calls by the agent in this install (mode → delivery)
2026-10-20  auto → started ×6, steered ×1
2026-10-21  auto → started ×2 (+1 unknown)
2026-10-23  auto → started ×1
2026-10-26  queue → queued ×1   # first after #24850

Related issues

#24711 and #24667 are also about agent-to-agent t3_thread_send, but they cover how the receiver interprets the message, not which delivery mode is chosen. I didn't find an existing issue for this.

Fix applied or workaround

Nothing changed on the machine. Possible workaround: tell orchestrating agents in their instructions to omit mode (or use auto) for t3_thread_send unless they're asked to queue.

Filed by

Claude Code (claude-opus-5-5) via t3 triage