[Feature]: Peer desktop clients as thin remote controllers of a primary desktop (desktop-to-desktop)

Issue Checklist

• I understand that issues are for reporting problems and requesting features, not for off-topic comments
• I have checked the pinned issues and searched through the existing open/closed issues and discussions, and did not find a similar suggestion
• I have provided a short, descriptive title

Platform

macOS. The scenario is platform-neutral (Electron / Web / Android / iOS).

Version

v2.0.14

Problem statement

Every current cross-device design assumes the remote endpoint is a phone:

• #16567 (remote agent access) — "Own mobile client (Expo / React Native)"
• #16392 (Cherry Cloud Relay and Mobile Entry) — mobile entry point
• #20262 / #20681 + cherry-studio-app#774 — LAN pairing so the mobile app can import desktop providers

Desktop-to-desktop is not discussed anywhere: a second desktop acting as a remote controller of the primary desktop's agent sessions.

Proposed scenario

One primary machine (A), always on, holds the single source of truth — sessions, messages, knowledge base, provider config, MCP. Other clients — phone B, laptop C — attach to A as thin remote controllers: read the live transcript, send prompts, approve tool calls. No local session store on B or C, and therefore no merge.

Why this seems worth considering

1. It removes the merge problem instead of solving it. A single source of truth plus stateless clients means no conflict resolution, no tombstones, no last-write-wins. This complements rather than replaces the merge/sync work in #15601 / #14898, for setups where the data is genuinely single-master.

2. The protocol already permits it. #16567 states "the hand-off boundary is the wire contract (@shared/ai/transport)" and puts mobile rendering out of scope — the contract does not appear to be client-type-specific. #18802 already targets "runtime-independent data and renderer clients" across Electron / Web / Android / iOS.

3. The shape already exists for browsers. #17315 (desktop remote WebUI) serves a browser UI from the Electron main process while session data stays on the desktop data plane — that is the same thin-client + single-data-plane model, with a browser as the follower instead of a desktop.

4. Reachability needs nothing new. Mode ① in #16567 (BYO URL: LAN / Tailscale / WireGuard) already covers a desktop follower.

Known trade-off (raised deliberately, not overlooked)

The primary must be online, and followers lose offline capability. That is the point of the model: where one machine is always on, it is simpler and safer than bidirectional sync. Users who need to work offline on both sides still need the merge path in #15601.

Scope

This is a scenario/design suggestion, not a PR offer. Raising it so that desktop-to-desktop followers can be in scope when the WS agent surface and the #18802 protocol are designed, rather than retrofitted afterwards.

Related

#16567 #16392 #18802 #17315 #14898 #15601