[Feature]: @ mentions for threads and projects as pointers the agent reads through t3-code tools

[IvanMatev]

Relationship to existing discussions

This builds on #6701, which covers tagging other threads and is in progress, and on #13888, which covers cross-project thread access with grants. The approaches discussed so far either inject the referenced thread's content into the prompt or send a sub-agent to search it. This proposal suggests a third approach: a mention is only a pointer, and the agent reads what it needs on demand through T3 Code's own tools. If maintainers would rather keep this in #6701, I'm happy for it to be merged there.

Problem

Context is siloed per thread and per project. When work spans several threads or repos, I end up acting as the clipboard: pasting plans, decisions and diffs between threads, or re-explaining what an agent has already worked out elsewhere. Injecting whole transcripts doesn't scale, because long threads flood the context window and most of what gets injected is irrelevant to the new task.

Proposal

Mentions become references. Typing @ in the composer also lists threads and projects, with fuzzy search by name. Picking one adds a thread or project record to the message's existing context field, which already accepts new record kinds, and places a chip in the text. No content is injected.
The agent reads threads on demand through the t3-code tool server. Every provider already receives this tool server, so a new threads toolkit works the same way for all of them:
thread_search(threadId, query), built on the existing orchestration.searchThreads
thread_read(threadId, turnId | range), to read specific turns or messages
thread_summary(threadId), returning the goal, key decisions, files touched and current status
@project gives read-only access to another workspace. The agent is given the project's workspace root, either as an extra read-only directory (the Claude adapter already passes additionalDirectories, and Codex supports writableRoots) or through scoped project_grep and project_read tools. Access to another project uses a grant the user sets, following the model in #13888.

Why pointers instead of injecting content

A mention costs almost nothing until the agent actually uses it.
Long threads don't flood the context window, because the agent reads selectively.
It behaves the same across providers and doesn't need a sub-agent.
Every lookup appears in the activity timeline, so access can be audited.
The user decides what the agent can reach, and the agent decides what's relevant within that.

Example use cases

"Update the client to match the API change we made in @backend-api-thread."
"Apply the same fix as @auth-refactor to this module."
Continuing a long or stale thread in a fresh one: "Pick up from @website-pipeline."
Asking a question that spans two related projects: "How does @pipeline-project call this endpoint?"

Open questions

Should a thread reference be live, so the agent sees a running thread's latest state, or a snapshot taken when the message is sent?
Should agents be able to search all threads without an explicit mention, or only reach threads the user has mentioned?
For @project, is it better to add the workspace as an extra directory or to go through scoped tools?