没有订阅怎么远程用 Claude Code？自建 Web 会话工具方案与选型

把 Claude Code 这类命令行 AI 编程工具跑在本地终端，麻烦往往不在模型能力，而在「人必须在机器前」。合上笔记本、通勤路上、或者只是切到另一台设备，正在跑的会话就断了，任务也没法下发。官方客户端里带远程能力的功能通常绑定订阅，于是有人干脆自己写一个极简的 Web 会话工具：浏览器里打开一个页面，就能把命令发给后端的 CLI，模型侧则接 GPT、GLM 等兼容接口，绕开对单一订阅的依赖。

这类自制工具的价值不在「炫技」，而在于把三件事拆开：会话常驻、任务下发、多端接入。理解这三件事，比照着某个仓库抄一遍更有用——因为每个人的场景差别很大，有人只需要在内网里给自己用，有人想从手机随时看进度，安全边界完全不同。

需求拆解：远程会话工具到底要解决什么

先把真实诉求列清楚，很多功能其实可以砍掉：

• 会话不随终端关闭而中断：进程要跑在服务端，而不是本地 shell 的子进程。
• 能从另一台设备下发任务：手机、平板、公司电脑都能连上，输入一条指令即可。
• 能看到输出和历史：不是只看最后一行，要能回翻上下文，最好支持中断正在跑的任务。
• 有最基本的鉴权：这一条经常被忽略，但恰恰是最重要的。
• 模型可替换：走兼容 OpenAI 协议的接口，后端换 GPT、GLM 或其他模型时不用改前端。

反过来，下面这些通常不是刚需：多用户体系、复杂权限模型、精美的 UI、完整的项目管理。砍掉它们，代码量可能只有原来的十分之一，用标准库就能写完，这在当前开源依赖投毒事件频发的背景下是实打实的优势——依赖越少，攻击面越小。

自建方案的最小架构

一个能用的版本只需要四层，每层都可以做到极简：

1. 进程层：用 PTY 拉起 CLI，而不是用 exec 直接跑。CLI 工具通常需要交互式终端，没有 PTY 会丢失颜色、光标控制和部分提示。
2. 传输层：WebSocket 双向通信最省心；只做单向输出展示的话，SSE 也够。
3. 接入层：一个单页页面 + 一个反向代理，代理层负责 HTTPS 和基础认证。
4. 保活层：服务进程交给 systemd、supervisor 之类的工具托管，崩溃自动拉起。

如果想先验证需求再动手写代码，用现成的终端复用工具就能模拟出八成效果：

# 在服务端开一个常驻会话
tmux new -s ai
# 任意设备 SSH 上来接管
tmux attach -t ai

这条路径零开发成本，缺点是移动端体验差、没有网页界面。是否值得为「手机上好用一点」写一整套服务，取决于你实际的使用频率。

现成工具怎么挑

讨论中被提到的项目不少，方向大致分三类。具体能力、维护状态和协议请以各自仓库的最新文档为准，不要只看别人的一句推荐就上手。

选型时按这个顺序判断，比看 star 数靠谱：

• 它要不要把 shell 暴露到公网？如果要，它自带哪些防护？
• 密钥存在哪里？如果存在浏览器 localStorage 或前端代码里，直接排除。
• 依赖有多重？一个只有几个源文件的工具，比拖几百个包的更容易审计。
• 能不能只监听内网？很多工具默认监听 0.0.0.0，需要自己改成 127.0.0.1 再走代理。

自建时最容易踩的坑

把 shell 暴露到公网

这是最危险的一条。一个能执行任意命令的 Web 接口，等于把服务器交给了互联网。至少要做到：强制 HTTPS、强口令或一次性 token、限制来源 IP、用独立低权限系统用户运行、必要时放进容器并限制可写的目录。不要把服务直接绑在公网 IP 的 80 端口上裸奔。

密钥写在前端

后端模型 Key 只能存在服务端环境变量或配置文件里，前端永远只跟自己的服务通信。顺便提醒：用第三方模型接口时，注意服务条款是否允许你所使用的场景，别把敏感代码发到不可信的中转上。

供应链风险

社区里有段时间 npm 生态投毒事件比较集中，这也是有人坚持「只用标准库」的原因。如果必须引入依赖，锁版本、提交 lock 文件、上线前跑一次依赖审计，都是低成本高收益的动作。

移动端细节

断线重连、输出缓冲上限、终端尺寸自适应，这三项不做，手机上基本没法用。输出缓冲尤其要设上限，否则长任务会把内存吃光。

不想造轮子的几条替代路线

• SSH + 终端复用：成本最低，安全模型成熟，适合 90% 的个人场景。手机装个 SSH 客户端即可。
• 只在内网访问：通过合规的企业 VPN 或内网穿透回到家里/公司的机器，服务本身只监听内网地址，不暴露公网。这是安全性和便利性平衡最好的做法。
• 云主机常驻：把 AI CLI 跑在一台长期在线的主机上，本地只做终端接入。缺点是需要自己维护系统和网络。
• 长期在线的远程 Mac：如果需要 macOS 特有的工具链，又不想让本地笔记本整夜开着，可以考虑整机放在机房的远程 Mac 租用方案——远程连接使用，长期在线跑 Claude Code 这类工具，网络环境相对稳定。它解决的是「本地设备不能常开、网络抖动导致会话中断」的问题，不是安全加固的替代品，鉴权和密钥管理仍然要自己做。

上线前的检查清单

• 服务只监听 127.0.0.1 或内网地址，公网访问统一走反向代理
• 已启用 HTTPS，证书自动续期
• 有强口令或多因素认证，禁止空口令
• 模型 API Key 仅在服务端读取，未出现在任何前端产物中
• 用独立低权限用户运行，禁用不必要的写权限
• 依赖版本已锁定，做过一次依赖审计
• 输出缓冲有上限，长任务不会拖垮内存
• 进程由守护工具托管，崩溃能自动重启
• 有一键停止会话的手段，异常时能立刻断开
• 定期查看访问日志，确认没有异常来源

小结

自制远程会话工具本身不难，难的是想清楚边界：你要的到底是「随时下发任务」，还是「随时随地拥有一个 root shell」。前者用 SSH 加终端复用就能覆盖大半，后者才需要一整套带鉴权的 Web 服务，而它的安全成本远高于开发成本。如果决定自建，从最小可用版本开始，先在内网跑通，再考虑是否对外；如果只是想省掉订阅，先算一算自己维护一台常驻主机的时间成本，往往比想象中高。

涉及官方客户端功能、订阅策略和模型接口协议的部分，时效性较强，请以官方最新说明为准。