核心定位：同步层，而非云迁移
Remote Control 是一个同步层（synchronization layer）或者说中继网关，而不是将工作迁移到云端。整个 Claude Code session 始终运行在你本地机器上，远程设备只是一个"窗口"。
网络连接的安全机制设计
本地 Claude Code 进程只发出出站 HTTPS 请求，从不在本机开放任何入站端口。当你启动 Remote Control 后，它向 Anthropic API 注册并开始轮询（poll）任务。当你从另一台设备连接时，Anthropic 服务器将消息在 Web/移动客户端与本地 session 之间通过流式连接（streaming connection）进行路由。所有流量通过 TLS 经 Anthropic API 传输，并使用多个短期凭证，每个凭证仅限单一用途且独立过期。
有三种方式开启：
claude remote-control（纯服务器模式，终端不再接受交互）
claude --remote-control（或--rc，交互式 session 同时开启 Remote Control）
在已有 session 中运行/remote-control
启动后终端会显示一个 session URL，按空格键还能显示二维码，方便手机扫码接入。
架构图
颜色对应含义： 绿色（本地机器）= 执行层，紫色（Anthropic API）= 中继层，蓝色（远程设备）= 控制层。
两条箭头方向不同： 虚线是本地主动发出的出站 HTTPS 轮询；实线是 API 将消息路由回来。本机从不监听任何入站端口，这是安全设计的核心。
中间那两个虚线框是整个架构最关键的边界：流经 API 的只有"聊天消息 + 工具结果"；源代码、MCP 服务器、文件系统全部留在本机，绝不通过 API 传输。远程设备"看到"的只是一个经过中继的对话视图，而非对本地文件的直接访问。
数据流与实现方式
顺着数据流向：
（1）远程设备 → 中继 API：没什么好说的，不过大概率不是普通短请求，而是 SSE 长连接，这样中继可以直接流式推结果给远端，不用远端自己轮询。
（2）安装 CC 的服务器提前主动向中继发出站 HTTPS 请求，把会话 sessionID 注册到中继，远程设备就可以通过中继查到这些 sessionID 然后"认领"（session URL / QR 码本质就是把 sessionID 暴露给远端）。之后中继维护一个 per-session 的消息 buffer，远程设备写，CC 本地轮询读增量——官方文档用的词就是"polls for work"。不过具体实现大概率也是 SSE 或 HTTP/2 streaming，而不是经典的短轮询。
（3）CC 本地进行处理，包括本地文件访问、MCP 调用、skill、调用 LLM 推理等等。
另外啰嗦一嘴：LLM 推理走的是另一条独立通道——CC 进程直接向 Anthropic API 发正常推理请求，和 Remote Control 的消息中继通道是两条分开的连接。中继层只负责转发"人类侧的输入/输出"，不经手推理本身。
（4）处理结果还是通过之前的连接，由 CC 本地主动写回中继层 buffer，中继再 flush 给远端设备的 SSE 连接，实现流式显示。
整个模型本质是"反向代理 + 消息 buffer"，CC 本地永远是主动出站方，中继从不向本机发起连接，所以不需要公网 IP、不用开端口——这是这个设计的精髓。
另外凭证这块文档提到"multiple short-lived credentials, each scoped to a single purpose"，暗示注册凭证、读凭证、写凭证可能是分开的 token，而不是一个 sessionID 走到底，安全隔离粒度更细。
