[FEATURE] Cross-account session messaging between accounts one person owns

Preflight

I searched the existing enhancement requests. Two are close, and I believe this is the gap between them:

• #89993 (first-class multi-account support) covers switching, credential binding, usage visibility, and rate-limit failover. It does not cover sessions on different accounts addressing each other.
• #87954 (cross-session conversation channel) covers two different people's sessions talking, gated by per-message human approval. This request is narrower and has no third party in it: one person, several accounts they already own, no other human to consent.
• #92058 asks to scope cross-session messaging to a project. Compatible with this, and the scoping it proposes would apply here too.

If maintainers read this as a subset of either, closing it as a duplicate is reasonable. I filed it because the same-owner case has a different trust model than #87954 and is not mentioned in #89993.

Problem Statement

Claude Code sessions under one login can message each other in realtime. Sessions under a different login cannot, in either direction.

The session tooling enumerates an in-memory map of sessions the app itself spawned under that login. A session started under a different config root is never entered into that map. It is not filtered out, it is never registered, so it cannot be listed or messaged.

I hold five Max 20x subscriptions on five accounts, because 20x is the largest tier sold. My work is therefore split across five app instances. Two sessions can sit in the same repository, on the same machine, at the same moment, under the same human, and be unable to address each other.

This is the single most expensive consequence of running multiple accounts. The other costs (config drift, uneven load, no usage visibility) are already well described in #89993.

Proposed Solution

Let a user pair accounts they own, and have the existing session primitives resolve across the pairing.

• A user opts in per account, from both sides, and can revoke. Pairing is between accounts one person controls. Never open addressing between arbitrary accounts.
• ListAgents lists sessions on paired accounts, labelled with which account owns each.
• SendMessage addresses them. Delivery semantics stay exactly as they are today.

Four constraints matter, because crossing a login boundary changes the trust model even when the human is the same:

1. Pairing is explicit and revocable. If any account could reach any other, an unrelated person's session becomes an injection source. That is a new attack surface rather than a widened one.
2. Peer-originated work runs under the receiving session's permissions, never the sender's. The receiver's grants are the ceiling.
3. Intersect permissions, do not union them. My five config roots do not carry identical grants today. Without this, a session denied an action could route around the denial by asking a paired peer that is allowed. Within one login that move buys nothing, because both sides hold the same permissions. Across logins it buys real privilege, and that is permission laundering with extra steps.
4. Keep the existing "this came from another session, not your user" envelope, and make the audit trail span the pairing. Today logs split per account, so a cross-account handoff is reconstructible from neither side.

Alternative Solutions

What I do today. A file-based mailbox inside .git, because a file write is the only transport blind to which login a session authenticated against. It works and it is asynchronous, so a message lands on the recipient's next turn rather than now. It has no presence, no delivery signal, and no addressing beyond a directory key.

The alternative that would remove the need entirely: sell a Max tier above 20x. I run five accounts only because 20x is the ceiling. A 50x or 100x tier would put my sessions back on one login, where the channel already works correctly and needs none of the trust model above. I recognise subscription tiers are not this repository's decision, and I am recording it here because it is the cheaper path to the same outcome, and because it explains why this request exists at all. I would buy that tier today.

Priority

High. Significant impact on productivity.

Feature Category

Configuration and settings.

Use Case Example

1. I run a coordinating session on account 1 and several worker sessions on accounts 2 through 5, across roughly 125 git worktrees of one repository.
2. The coordinator finishes scoping a task and needs to hand it to a worker that has quota headroom.
3. Today it cannot see or address that worker at all, because the worker is on another login. It writes to a file in .git and the worker picks it up on its next turn.
4. With paired accounts, the coordinator calls ListAgents, sees the worker, and calls SendMessage. The handoff happens now instead of eventually.
5. This would remove the mailbox layer I maintain, and remove the class of bug where a message is written correctly and simply never read.

Environment

• Claude Code on Windows 11, Desktop app and CLI.
• Five config roots (~/.claude-account-1 through -5), five distinct account emails, five separate pools.