[Feature]: 远程开发支持 — 会话级 SSH 远程执行 + 多 server 聚合（求方向意见）

[hackxixi]

Before submitting

• 我已搜索现有 issue，未发现重复。
• 我描述的是具体问题或用例，而非笼统想法。

Area

apps/server 与 apps/web（两条路线分别偏重），并涉及 packages/contracts、apps/desktop。

问题 / 用例

我想在本地用 PeakCode 的同时，使用一台异地、经 SSH 可达的机器（开发机 / 服务器，代码在那台机器上）做开发，并在一个界面里统一管理。

目前 Web 客户端是单连接的、agent 都在 server 本机起子进程，没有任何远程能力——要用远程机器只能在那台机器上单独跑一套、再开浏览器去连，彼此割裂。

提议方案

两条互补路线，想听维护者的方向倾向：

路线 A — 会话级 SSH 远程执行（改动小、远程零安装）

• 单个本地 PeakCode server，把单个线程的 agent 经 SSH 派到远程主机执行（代码在远程）。
• UI：现有「Continue in」环境选择器（Local project / Worktree）加第三项 Remote (SSH)。
• 技术上很顺：Claude Agent SDK 的 spawnClaudeCodeProcess 钩子 + Node ChildProcess 直接满足其 SpawnedProcess 接口，远程会话 = 本地 spawn("ssh", …, "--", claude, …)，JSON-RPC 走子进程 stdio，事件流 / 审批 / turn.diff.updated 全部照旧；gateway 用 ssh -R 反向隧道回到本地，命中现有 loopback sentinel 鉴权。
• 代价：远程线程要降级本地专属面板（文件树 / git / 终端 / 在编辑器打开等），因为这些功能假设代码在 server 本机。

路线 B — 多 server 聚合（功能完整对等、客户端重构较大）

• 每台机器各跑一个完整 PeakCode server，单个 Web 客户端同时连多台、统一管理；远程的 git / 终端 / 文件树在各自机器本地，功能完整对等。
• UI 倾向树形 Server › Project › Thread（或顶部切换器）。
• 远程鉴权复用 WS URL 的 ?wsToken= / ?token=（浏览器 WebSocket 不能带 header）。

为什么重要

「本地 + 远程开发机」是很常见的工作流；一个界面跨机器看到所有 agent 活动，避免多窗口割裂。这也是把 PeakCode 用于「远程主机上的 coding agent」的两条务实路径。

最小可用范围

• 路线 A：「Continue in」加 Remote 选项 + 一份远程主机配置（host / remotePath，可选 user / port / identityFile），能把一个会话跑在远程；本地专属面板降级即可。
• 路线 B：先做基础设施——把客户端「单连接假设」改成「server 注册表 + 活跃指针」（Phase 0 零行为变化），再支持连第二台 + 添加 server 表单（Phase 1）。

已考虑的替代方案

• 开多个浏览器标签各连一台：状态割裂、无法统一管理。
• 把单个 server 改造成支持远程 fs / git / 终端（ExecutionBackend 抽象 / 远程伴随运行时）：功能对等最彻底，但与本地耦合深、工作量大。路线 A 更轻；路线 B 用「每台各跑完整 server」绕开这层耦合。

风险 / 取舍

（基于初步读码）

• 路线 A：ThreadEnvironmentMode 是天然扩展点（加永久字面量 remote），但 local/worktree 与 local/remote 是正交两轴（host × workspace），把 remote 当第三项是 MVP 捷径——建议把 host 细节放进判别联合 RemoteHostConfig，为将来两轴拆分留路。下游一切本地 fs / git / 终端 / realpath 校验都假设 cwd 是本机真实路径，远程需降级或旁路。
• 路线 B：传输 / API 是模块级单例，ensureNativeApi/readNativeApi 被约 179 处调用——用「注册表 + 活跃 server 指针」可让多数调用点零改动；主 store 扁平、无 serverId（可外层分片 Record<ServerId, AppState>）；TanStack Query key 不含 serverId；事件中枢假设单一事件流，需按来源 server 分流。workspaceStore 是现成蓝本。

想征询的意见

1. 维护者对远程开发支持的整体态度？是否契合 local-first / 隐私优先的定位？
2. 更倾向先做路线 A（轻、快）还是路线 B（完整、重）？还是两者都要？
3. 是否已有相关规划，或更想要的架构方向？
4. 若方向 OK，是否欢迎以 PR 形式贡献？（我愿意实现）

Contribution

• 我愿意参与实现。