Let a thread message threads in other projects, with a grant the user sets

[mkiera]

This is about the orchestrator MCP tools on the orchestration v2 branch (#2829), which is not on main yet.

Problem

A thread can send to, wait on, and interrupt threads in its own project only. t3_thread_send, t3_thread_wait, and t3_thread_interrupt look the target up under the caller's project (loadScopedThread in apps/server/src/mcp/OrchestratorMcpService.ts). t3_thread_read can also read a thread outside the project when the user attached it to one of their own messages.

I keep a management project whose threads coordinate work in my other projects. There is no supported way for a thread there to hand a task to a thread in another project and get the result back. I have to copy messages between threads by hand.

Proposal

The first step covers projects on the same environment.

Grant. From a thread's action menu, the user picks which other projects on this environment the thread may reach. Only the user can set or remove it. An agent cannot widen its own grant through MCP, the same rule that already limits reads of attached threads to records the user wrote (userAttachedThreadIds).

What a grant allows. In the granted projects, the thread can use:

• t3_thread_list and t3_thread_read
• t3_thread_send with mode auto or queue
• t3_thread_wait

restart sends and t3_thread_interrupt stay limited to the caller's own project. The existing resolveRuntimeMode and resolveInteractionMode checks apply unchanged, so the caller cannot start work in a thread with a broader mode than its own. Approvals stay with the target thread and are answered by the user as usual.

The grant is one-way. It gives the threads in the granted projects no reach over each other or over the sending thread.

Replies. t3_thread_send already records senderThreadId. For a message from another project, the target's timeline shows the sending thread and project. While the grant exists, the target may send back to that one thread with mode: "queue". It cannot read the sender's history or reach anything else in the sender's project.

Loop limit. A thread that receives more than a fixed number of cross-project messages in a row (for example 10) with no message from the user in between stops accepting them. They wait in the queue until the user sends a message or clears the queue.

Tool changes. t3_thread_list takes an optional projectId filter and returns each thread's projectId. The other tools keep taking a thread ID, and the server checks it against the caller's grant. clientRequestId already makes retries idempotent, so a lost response does not start duplicate work.

Removing it. Removing a grant blocks further sends and replies right away. Messages already queued on a target stay there, where the user can see and cancel them. Deleting or archiving the sending thread removes its grant. The thread header shows when a grant is active, on web, desktop, and mobile.

Later: other environments

My actual setup has the management project on my PC and the coding project on a VM. I'd like the same grant to reach threads on another environment, but that needs design decisions I don't want to bundle into the first step:

• One server would hold a session on another server. Today only clients do.
• v2 has no HTTP endpoint for sending, only for reading thread state. Sending goes through the WebSocket.
• The destination would need its own list of which projects the source may reach. Pairing scopes cover types of operation, not projects.
• Cutting the source off means revoking its client session (revokeClient). Revoking the pairing link alone does not do that.
• The source server has to reach the destination itself, over a direct URL, Tailscale, or a T3 Connect tunnel. Reachability from the user's own client isn't enough.

Is cross-environment messaging something you'd consider? If so, I can write it up as a separate proposal after the same-environment version.

[kvnloo]

I like the same-environment-first boundary.

I'd consider making the user grant a first-class durable capability rather than only an allowlist checked ad hoc: sourceThreadId, targetProjectId, allowed operations, max runtime/interaction authority, optional expiry, and explicit user revocation. MCP calls can reference that grant ID.

That gives us one auditable/revocable authorization primitive now, and a clean path to cross-environment later where the same grant can be bound to an authenticated remote principal instead of inventing a second ACL model.

I'd also carry a clientRequestId plus sender/correlation metadata on cross-project sends so retries are idempotent and message chains remain traceable.