[FEATURE] Reviewable message relay: thread-to-thread and thread-to-session messaging

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

I run a hierarchy of persistent threads: several Home/chat threads act as "tech leads" (strategy, methodology, research direction). Each tech lead delegates execution work to its own dedicated Code session, and separately collaborates with other persistent Home/chat threads that act as helpers with specialized skills — not formally launched or owned by the lead, but working alongside it on an ongoing basis. For example, one tech-lead thread might rely on a separate persistent thread specialized in finding patterns or anomalies in unstructured data streams to continuously review output on its behalf. This is a two-way, ongoing collaboration: the helper reports findings back, and the lead can respond by asking the helper to look deeper into something specific, or redirect its attention toward what currently matters most — not a one-off task or a successor handoff.

Normal day-to-day operation of this structure requires frequent thread-to-thread communication in several directions: a lead delegating a task to its Code session, a Code session or helper thread reporting findings back to the lead it's supporting, the lead refining or focusing the helper's attention in response, one lead requesting input from another, or one lead proactively informing another lead of important new information it has discovered. All of this currently happens through the same manual mechanism: copy content out of the source thread, switch to the target thread, paste it in.

This works, but it's pure mechanical overhead on every single exchange — the user acts as a message router for routine, ongoing collaboration between threads, not just for occasional one-off handoffs. As the number of active threads grows, this manual relay becomes the dominant cost of running a multi-thread workflow.

This is distinct from existing requests like #27441, #37213, #35072, #36181, and #24798, which describe Claude Code session-to-session coordination for multi-agent coding workflows, several explicitly requesting autonomous, human-out-of-the-loop messaging between peer Code sessions. This request covers Home-to-Home (including between independent collaborating threads), Home-to-Code, and Code-to-Home communication for normal operation, and explicitly keeps a human review step by design.

Alternative Solutions

The only in-product alternative is fully manual relay — copying content out of the source thread, switching to the target thread, and pasting it in. Call it sneakernet: it works, but does not scale, since the user spends an increasing share of their time acting as router and courier, constantly switching between threads, rather than doing the actual work each thread exists to support.

I attempted a workaround using the Google Drive connector (available to both Home/chat and Code) as a shared message-drop folder: any thread writes a text file addressed to another, and the target thread reads it when prompted to check. In principle this would cover Home-to-Home, Home-to-Code, and Code-to-Home.

In practice, it's blocked: #39422 means the Drive connector, though enabled in claude.ai, does not reliably pass through to Claude Code sessions, breaking the Home-to-Code and Code-to-Home directions. Separately, #86771 is worth flagging on its own: the Drive connector's consent screen claims "only the specific files you use with this app," but the actual OAuth grant includes drive.readonly, full-Drive read access. Most users won't audit scopes themselves — they trust the screen and click through.

With the Drive workaround blocked, sneakernet remains the only thing that actually works today — and it does not scale.

Alternative Solutions

The only in-product alternative is fully manual relay — copying content out of the source thread, switching to the target thread, and pasting it in. Call it sneakernet: it works, but does not scale, since the user spends an increasing share of their time acting as a message router rather than doing the actual work each thread exists to support.

I attempted a workaround using the Google Drive connector (available to both Home/chat and Code) as a shared message-drop folder: any thread writes a text file addressed to another, and the target thread reads it when prompted to check. In principle this would cover Home-to-Home, Home-to-Code, and Code-to-Home.

In practice, it's blocked: #39422 means the Drive connector, though enabled in claude.ai, does not reliably pass through to Claude Code sessions, breaking the Home-to-Code and Code-to-Home directions. Separately, #86771 is worth flagging on its own: the Drive connector's consent screen promises "only the specific files you use with this app," but the actual OAuth grant includes drive.readonly, full-Drive read access. Most users won't audit scopes themselves — they trust the screen and click through.

With the Drive workaround blocked, sneakernet remains the only thing that actually works today — and it does not scale.

Priority

High - Significant impact on productivity

Feature Category

Other

Use Case Example

A tech-lead thread ("RTS") is delegating a coding task to its dedicated Code session, and separately relies on a helper thread ("Evidence") that continuously analyzes log output from a long-running process for anomalies. Right now:

1. When Evidence finds something worth flagging, I copy its finding out of the Evidence thread and paste it into RTS.
2. When RTS wants Evidence to look more closely at a specific time window or pattern, I copy that request out of RTS and paste it into Evidence.
3. When RTS's Code session finishes a task and reports results, I copy that output from the Code session back into RTS.

With this feature: RTS could draft "ask Evidence to check for X in the last hour of logs" and send it directly to Evidence, pending my one-click approval. Evidence's findings could be drafted as a message back to RTS the same way. Over a single day running 5-6 active threads like this, this would eliminate dozens of manual copy/switch/paste cycles, while I still see and approve every message before it's delivered.

Additional Context

This request is specifically about the Claude Desktop app for macOS (distributed from the Claude Code product page, containing both a Home tab and a Code tab). The lack of thread-to-thread messaging compounds with two other gaps in the same app: there is no reliable way to tell, at a glance, when a given thread has produced new output ready to review (the previous sidebar unread-indicator was removed and closed as not planned in #32628), and Home/chat threads have no compaction mechanism (/compact, /clear, /context are Code-session-only). Together, these make managing several persistent, ongoing threads harder than it needs to be: no passive signal for new output, no way to compact a long-running thread proactively, and no way to relay information between threads without manual copy/paste.