Sign up
View stargazersSign up

[Bug]: Agent-to-agent thread sends reach the receiving model as if the user wrote them#24711

opened18d agobyHhinescreative

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

  1. In one project, start a parent thread and have it create a child with delegate_task (mode async).
  2. From the child thread, call t3_thread_send to the parent (steer or queue) with a plain sentence, for example "Please merge the PR now."
  3. Read the parent's next provider turn (transcript or provider logs) and the parent thread through t3_thread_read.

Expected behavior

The receiving agent can tell that the message came from another thread's agent, not from the user. The provider-bound text carries the sender (thread title or id) and that it was agent-authored, the same facts the stored timeline item already records.

Actual behavior

The receiving agent gets only the raw message body as a user turn: no sender, no agent marker. t3_thread_read on the parent shows the item with senderThreadId set to the child, createdBy: agent and creationSource: mcp, and the UI shows that provenance, but the text sent to the provider drops it. The parent agent reads the child's sentence as the user's instruction.

Impact

Any multi-agent setup (delegated tasks, sibling threads coordinating with t3_thread_send) lets one agent's message pass as the user's. Agents then act on requests the user never made, or attribute decisions to the user. We hit it in daily use: a child's status message was taken by the parent as a user directive.

Version or commit

T3 Code nightly (macOS desktop). The behavior is in apps/server/src/orchestration-v2, where provider text is assembled for new turns (ProviderTurnStartService) and steers (ProviderTurnControlService).

Environment

macOS 26, desktop app, Claude, Codex and OpenCode providers; the behavior is provider-independent because it happens before any adapter.

Logs or stack traces

None needed: no error is raised. The stored timeline item has the provenance fields; the provider-bound message does not.

Notes

An earlier PR for this, #24483, has to be replaced: its code was written by a model this repository does not accept. A fresh fix written by an accepted model will link here.

AAngeloTadeucci11d ago
Synced from GitHub

Note

Claude Opus 5.5 responding on behalf of Ângelo.

Another repro, with Claude threads on Windows.

One thread sent a status update to another with t3_thread_send. The UI labelled the folded message with the sender thread's title. The receiving agent got only the body. It said it couldn't tell which session had sent the message, then searched Claude Code's own list of local peer sessions for the sender. T3 threads aren't on that list, so it found no match and answered in its own thread instead.

So the missing provenance does more than make agent text look like the user's. The receiver also has no way to reply.

The code on main matches the report:

  • OrchestratorMcpService.ts:2847 stores senderThreadId on the message.
  • TimelineUserMessageRow.tsx:444 uses the sender's title to label the folded row in the UI.
  • ProviderTurnStartService.ts:1022 builds the provider text from only the message body and composer context. No provider adapter reads senderThreadId.

#24725 adds a prefix to that text that includes the sender's thread id, which would have fixed this case. In my judgement, it would also help to name t3_thread_send in the prefix, so a Claude agent doesn't reach for its native messaging first.