Thread links open the thread on whichever connected machine has it

[royalaid]

Problem

Agents link threads as [title](t3-thread://v1/<threadId>). The client looks that id up only in the environment of the message holding the link. When the linked thread lives on another machine, the link shows its written label with "Thread no longer available", and clicking it opens the current machine's route for an id that machine doesn't have, which lands on a new draft. That happens even when the same client is connected to the machine that has the thread and lists it in the sidebar.

I run T3 Code on a Mac and a Windows desktop, with one client connected to both, and agents on each machine hand work across and link the threads they mention. Those links don't resolve. Asking the Mac's server for a thread on the desktop (t3_thread_read with 44ca5495-b9ab-43f9-8b0a-5d4870c8a923) returns thread_not_found ... is no longer available, and the client does the same single-environment lookup.

Where this happens on main (52a769d):

• The contract says the id resolves only in the message's environment: packages/shared/src/threadLinks.ts#L5-L9
• Web reads the shell from the message's environment and routes there: MarkdownThreadLink.tsx#L22-L37
• Mobile labels links from one environment's titles and navigates to the feed's environment: entities.ts#L43, ThreadFeed.tsx#L1827

The client already has what it needs to do better. It keeps a thread index per connected environment (threadShell.ts#L141) and already walks every enabled environment to build the sidebar (threadShell.ts#L332-L334).

Reproduction

Two dev servers with separate state on one Mac, A and B, and a web client on A paired to B through Settings > Connections > Add environment. On B, a thread titled "Thread on box B". On A, a message containing [box thread (old label)](t3-thread://v1/<that thread's id>).

On main, the link shows its written label, a generic icon and "Thread no longer available":

Clicking it goes to /<A>/<B's thread id>, which A doesn't have, so it lands on a new draft:

History

• feat(server,web,mobile): agents see snooze state and link to threads #16782 introduced links as t3-thread://v1/<environmentId>/<threadId>, with tools returning a ready link and a baked title.
• fix(server,web,mobile): thread links reference the thread id, not a baked title #17017 made the id the only reference and dropped the environment segment, because baked labels went stale and agents copied them around as if they were the source of truth. Since then links resolve in the message's own environment, "the same way the composer's thread references do".

This proposal keeps #17017's model. The id stays the only reference, and the label is still only a fallback.

Proposed behavior

Client-side resolution only. No change to the link format, contracts, server, or what agents are told to write.

1. Look the id up in the message's own environment first, exactly as today.
2. If that environment has no such thread, look it up in the other environments the client is connected to, using the per-environment thread index the client already keeps.
3. If one of them has it, show that thread's live title and project icon and open it at /$environmentId/$threadId there.
4. If several environments have it, the message's own environment wins. If several other environments have it, the first enabled one in the client's environment list wins. Thread ids are UUIDs in practice, so this tie-break should rarely matter.
5. If none has it, keep today's behavior: the written label, "Thread no longer available", and a link into the message's own environment, which still opens an archived thread there.

Web and mobile share the lookup (packages/shared for the id forms, packages/client-runtime for the cross-environment index), so mobile gets the same labels and tap behavior.

As a cheap side effect, the few links written in #16782's short-lived v1/<environmentId>/<threadId> form (on nightly for about a day) would resolve by their thread id. Nothing would emit that form again.

With this behavior, the same link from the reproduction shows B's live title and icon:

and opens /<B>/<thread id>, B's thread:

Performance

The lookup reads the thread indexes the client already maintains. It builds one id-to-environment map per message environment and only publishes a new value when a linkable thread appears, moves or is renamed, so status updates, streaming and other shell traffic don't re-render links. No new server requests or websocket traffic.

What it deliberately does not do

• It doesn't bring back an environment segment or a baked title, and it doesn't change agent instructions or MCP tool output.
• It doesn't reach environments the client isn't connected to, disabled environments, or archived threads on another machine (the shell stream leaves archived threads out of the index, ShellStream.ts#L301). Those fall back to today's behavior.
• It doesn't change server-to-server linking, delegation, or attached-thread context.

Alternatives considered

• Put the environment back in the link (v1/<environmentId>/<threadId>). Most precise, but it reverses fix(server,web,mobile): thread links reference the thread id, not a baked title #17017 and makes agents responsible for another id that has to be right. The id-only form already identifies the thread; the client just needs to look further.
• Resolve on the server through linked environments (feat(server): link to another environment #16655, feat(server): agents use linked environments through any T3 tool #16684). That serves agents, but in-chat links are a client concern, and a client can be connected to machines that aren't server-linked to each other. A client-side lookup works today without peer links and keeps working when they land.
• Let agents pass an environment hint only when they know it. Adds a second link form and an agent rule for a case the client can answer from data it already has.

Overlap and duplicates

I searched issues, PRs and discussions for thread links across environments and found no existing proposal or open PR that changes how t3-thread:// links resolve.

• julius's peer-link stack (feat(server): link to another environment #16655, feat(server): agents use linked environments through any T3 tool #16684, feat(web,mobile): linked environments in Connections #16698, feat(server): delegate_task to a linked environment #16719, feat(server,web,mobile): an agent sets up a link to another environment #17129, feat(server,web,mobile): @-mention a machine, and linked environments become a Labs beta #17130, feat(web,mobile): Continue on… a linked environment #16758) links servers and lets agents work on linked environments. It doesn't touch link parsing or rendering. This proposal follows the gate kept in feat(server): delegate_task to a linked environment #16719 and feat(web,mobile): Continue on… a linked environment #16758: open another environment's thread only when the client is connected to it.
• Desktop: copy a deep link to a thread #19531 and feat: link to a message in a thread from anywhere #19203 cover OS and hosted deep links (t3code://threads/<environmentId>/<threadId>), which already carry the environment. Here it's the in-chat t3-thread:// link, which by design doesn't.
• fix(composer): don't send attached threads to a machine that can't read them #18310 and fix(mobile): don't send or paste attached threads a machine can't read #18322 stop attached threads from being sent to a machine that can't read them. That's the composer's context references, a separate path.

Implementation available

I have a potential implementation ready if this is approved, or as something concrete to discuss scope against: royalaid/t3code thread-links-cross-environment. It's two commits on top of 52a769d (code with focused tests, plus a one-sentence update to docs/orchestration-v2/orchestrator-mcp-server.md), written with Claude Opus 5.5 in Claude Code. The tests cover: a thread only another environment holds, a thread both hold, a thread none holds, percent-encoded ids, the old link form, and the index staying stable across unrelated updates. vp check and vp run typecheck pass. I haven't opened a PR and won't until the direction and scope are approved here.

Ask

Would a maintainer approve this direction and scope (client-side cross-environment lookup for t3-thread:// links, own environment first, no format change)? If you'd prefer a different tie-break, or want mobile left to a follow-up, I'll change the scope to match.

[juliusmarminge]

Note

Grok responding on behalf of Julius.

This landed in #21505. A t3-thread:// link is looked up in the message's own environment first, then in a unique match across the other enabled connected environments. Missing or ambiguous targets keep today's fallback. Thanks for the detailed write-up. Closing as resolved.