t3_thread_send never wakes the sending agent when the target's run finishes

[piotrski]

What happened

An orchestrator agent thread coordinates other threads through the T3 MCP tools.

• delegate_task children wake the orchestrator when they complete. This works.
• t3_thread_send to a thread that already exists, such as a long-lived thread the user started, gives no wake. The target finishes and the sender stays idle.

The orchestrator can't keep a promise like "I'll tell you when it's done". The delegate_task result says "Completion wakes this thread, so end your turn. Do not wait on it or poll it.", and t3_thread_send documents no equivalent. The user found finished work only by asking, and eventually asked "Why didn't you notify me about this again?"

Diagnosis

• The only completion wake comes from the delegated-task path. In the sender thread, every server-originated message is a "Delegated task …" completion. None comes from a t3_thread_send target.
• A t3_thread_send message records senderThreadId and nothing else. The source has no consumer that turns the target's run ending, or asking a question, into a message to that sender.
• The tool description in apps/server/src/mcp/toolkits/orchestrator/tools.ts promises no wake. The "do not poll" guidance in packages/contracts/src/orchestratorMcp.ts applies only to delegated tasks.

Steps to reproduce

1. In an agent thread A with the T3 MCP tools, call t3_thread_send with the threadId of an existing thread B that A did not create with delegate_task.
2. End A's turn and tell the user you'll report when B is done.
3. Let B's run finish.
4. A never receives a message. It stays idle until the user prompts it or it calls t3_thread_wait or t3_thread_read.

Expected: A is woken with B's final message, error, or pending question, as with delegate_task.

Version

Unknown. The desktop app and server on this machine are 0.1.6-nightly.20261031.3977, but I could not confirm that is the build the thread ran on. I read the same version's source.

Environment

macOS (darwin arm64), T3 Code Desktop with a local server, Claude provider.

Evidence

Read-only database queries on the affected install. The orchestrator thread (A) sent messages with t3_thread_send to existing threads that were not its children (no parent lineage). Each target's run completed, and A received no server message afterwards:

Target	Description	Run completed
Thread B	User-started, long-lived investigation thread	2026-10-31 12:50:01Z
Thread C	User-started setup thread	2026-10-31 13:33:35Z
Thread C	Same thread, a later run	2026-10-31 14:52:42Z

A's next messages were from the user, not from a wake:

• 12:55Z, about 5 min after B completed.
• 13:41Z, about 8 min after C completed.
• 13:59Z, about 26 min after C completed: the user asked whether thread C was ready.
• 14:00Z: "Why didn't you notify me about this again?"

Delegated children did wake A every time. Server messages arrived at 14:30Z, 15:04Z, 15:16Z and 15:31Z.

Related issues

• [Bug]: Parent is never notified when a delegated child's provider-initiated run ends (e.g. after a background command finishes) #21772 (closed): a parent isn't notified when a delegated child's provider-initiated run ends.
• A lower-mode thread can't report back to the thread that launched it, and the refused send is invisible #26293 (open): a lower-mode thread can't report back to the thread that launched it.

Workaround

None that keeps the sender hands-off. delegate_task only creates new child threads, so it can't be used to orchestrate a thread that already exists. The only options are polling with t3_thread_wait or t3_thread_read (which the tool docs discourage), or having the user ask the sender for status.

Agent

Produced by Claude Sonnet 5.5 (claude-sonnet-5-5) in Claude Code, running inside T3 Code's triage flow.

[timjonaswechler]

One idea to extend this: let an agent explicitly subscribe to the completion of an existing thread, optionally targeting a specific run.

The observing agent could then end its turn, and T3 would automatically wake it when the watched work finishes—without polling, timers, or the watched thread having to send a message.

An optional “wait until fully settled” mode could include delegated/background work and the thread’s processing of those results. The notification should distinguish success, failure, cancellation, and being blocked on input.

Ideally, subscriptions would survive restarts, avoid duplicate wakes, and handle work that finishes just before or during registration. This could be opt-in, leaving ordinary t3_thread_send behavior unchanged.