Let agents message existing sibling threads

[BrianLYS]

Note

Implementation PR: #6573 is ready for review. It implements the proposed thread_list and thread_send scope for existing active same-project threads; thread creation remains outside this proposal.

Problem

Independent T3 threads in the same project cannot address one another. A user can run several durable threads, potentially on different providers or worktrees, but an agent must ask the user to manually carry a question, result, or warning between them.

A T3 thread is the durable address here. The feature should not couple one live provider process to another or share provider conversation state.

Proposed smallest useful scope

Expose two provider-neutral tools through T3's existing authenticated MCP server:

thread_list()
thread_send({ threadId, message })

thread_list returns a bounded list of active sibling threads in the invoking thread's project, with stable T3 thread IDs, titles, runtime state, branch/worktree context, and update time.

thread_send dispatches a bounded text message to one existing sibling thread. T3 derives the source thread from the provider-scoped MCP credential, validates the source and target in the orchestration decider, and persists the target message and turn request before starting or resuming its provider session.

The target receives a server-authored attribution envelope such as:

> Message from T3 thread **API review** (`thread_abc`) via T3 Code
> Reply using `thread_send` to `thread_abc` only if useful.

Please verify the pagination behavior.

If the target is idle, its provider session starts or resumes. If it is already running, delivery follows T3's existing steering semantics. The sender receives an acceptance receipt after the target turn intent is durably committed, not after the target finishes.

Trust boundary

• Same environment and same project only.
• Existing, active, non-archived target threads only.
• Self-send is rejected.
• Routing uses stable T3 thread IDs; titles are display-only.
• Sender identity is server-derived and cannot be supplied by the agent.
• Text only, with a small coordination-oriented size limit.
• Messages are explicit tool calls; no automatic reply or blocking wait.

The MCP handler must dispatch through the orchestration engine. It must not call ProviderService.sendTurn directly, because T3's durable message and turn-request events must commit before provider execution.

Non-goals

• Creating or spawning threads
• Agent profiles, roles, budgets, or a run graph
• Sharing Codex conversation state or resume cursors
• Cross-project or cross-environment delivery
• Reading another thread's transcript
• Waiting for or aggregating results
• Moving or merging worktree changes
• Replacing provider-native subagents
• A new settings or coordinator UI

Broader agent orchestration remains complementary; this proposal is limited to a small messaging primitive between existing threads.

Acceptance criteria

• Any provider with T3's MCP connection can list active sibling threads in its current project.
• An agent can send a self-contained text message to one sibling by stable T3 thread ID.
• T3 durably records the attributed target message and turn-start intent before provider execution.
• A stopped target session can be started or resumed through the ordinary provider reactor.
• Cross-project, self, archived, missing, blank, and oversized sends fail explicitly.
• Focused tests prove authorization, attribution, durable dispatch, and negative cases.

I am open to implementing this as a small server-focused PR if the boundary fits the project's direction.

[rcawston]

I wholly agree that this should be available, and exposing it on T3's existing MCP is not really new surface. thread.create, thread.turn.start, and the orchestration read APIs already exist. The gap is simply that in-session agents cannot easily use them, so the human has to ferry messages between sidebar threads.

Codex and Claude Code both already have this kind of visible-session coordination. T3 should treat thread_list / thread_send as native MCP utility.

I'd also include thread_create, behind a preference:

• disabled: not available to agents
• manual: suggest a new thread (Claude-style tile) and wait for the user
• automatic: just start it (Codex-style)

That keeps the scope small, but does not force Coordinator/Dev-style loops to stay one-way on pre-created threads.

[rcawston]

My fork with working thread tools MCP built-in: https://github.com/rcawston/t3code .

Working well for me so far, where I have one Orchestration/Architect thread spawning and talking back and forth with Developer threads.

[respectTheCode]

Any progress here?

Coming from herdr, I really miss being able to have one agent check in on others.