Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Chiusa Adatta ai principianti
  • Qualcosa non va?
#25,447 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
68/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
developer-experience

Direzione di ricerca

Trova la descrizione dello strumento t3_thread_send e lo schema di OrchestratorMcpThreadSendInput.mode; l’issue non specifica i relativi percorsi dei file. Leggi la copia e lo schema attuali, poi aggiornali in modo che auto sia l’impostazione predefinita normale e queue serva per un turno successivo deliberatamente separato. Il lavoro è concluso quando entrambe le descrizioni indirizzano l’agente verso auto, a meno che queue non sia esplicitamente previsto.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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

Lingua principale
TypeScript
Stelle
24.8k
Fork
6.4k
Merge medio
2h 54m
PR unite (30g)
350

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di pingdotgg/t3code

Tutte le issue di pingdotgg/t3code

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.