咖啡馆 Wi-Fi 切换后，本地终端关闭，Claude Code 的任务上下文也跟着消失。
最快解法：不要把长时间运行的任务绑在随身设备上。让云端 Mac 承载代码、工具链和任务状态，iPad 或轻薄本只负责远程操作；确实需要离线时，再保留本地环境，形成“云端执行、本地应急”的双轨方案。
这篇文章适合只带 iPad 或轻薄本出行、但项目仍依赖 macOS 工具链的独立开发者；也适合经常切换酒店、咖啡馆和共享办公网络，需要保持 Claude Code 任务连续的人。如果你担心随身电脑损坏或丢失后无法立即恢复开发环境，下面的时间线可以直接照做。
最后更新于 2026 年 8 月 20 日，数据核实自 Anthropic Claude Code 官方文档与 Apple 官方 macOS 远程访问文档。
先划分任务：云端执行，还是本地保留
旅行开发最容易犯的错，是先安装工具，再考虑网络断开后怎么办。正确顺序相反：先判断项目能否接受远程依赖，再决定 Claude Code 放在哪里运行。
Anthropic 官方文档确认，Claude Code 支持 macOS，运行需要联网完成身份验证和 AI 处理；官方安装页面还列出 macOS 10.15 或更高版本、4 GB 以上内存、Node.js 18 或更高版本等要求。这里的硬性条件会直接影响你的远程方案：云端 Mac 需要在线，随身设备不必承担完整运行环境。(Claude Code 官方安装文档)
| 任务类型 | 推荐位置 | 原因 | 断网后的处理 |
|---|---|---|---|
| 普通代码阅读、测试、重构 | 云端 Mac | 环境集中，跨设备进入 | 从另一台设备重新连接 |
| 需要 macOS 工具链的构建任务 | 云端 Mac | 保持系统、运行时和依赖一致 | 本地只保留应急分支 |
| 无网络也必须继续的编辑 | 本地设备 | 不依赖远程入口 | 网络恢复后再同步 |
| 生产环境授权、密钥轮换 | 本地或受控双轨 | 风险高，不能交给无人值守任务 | 等你重新在线确认 |
| 大量图形界面操作 | 云端 Mac + 受控桌面 | 需要可视化 macOS 环境 | SSH 作为备用入口 |
你可以用下面的判断分支快速决定：
- 若项目依赖 macOS、每天跨设备切换，且旅途中基本能保持联网，则选云端执行。
- 若项目需要长时间离线、频繁连接物理设备，或必须在本机完成安全授权，则保留完整本地环境。
- 若项目同时满足 macOS 依赖和高风险交付要求，则采用双轨：云端 Mac 做主环境，本地设备保存可启动的应急工作流。
- 若你只是偶尔运行短任务，不需要保存长期上下文，则没有必要为了 Claude Code 单独迁移全部开发环境。
这也是“数字游民开发工具”选择的核心：不是把所有软件搬到云端，而是把最难重建、最怕中断的部分放到稳定位置。
出发前建立最小环境：不要复制旧 Mac 的全部配置
第一次使用云端 Mac，不要把旧电脑的整个用户目录、缓存、密钥和历史配置一股脑复制过去。配置越多，出错边界越大；项目越复杂，断线后越难判断到底是网络问题、依赖问题，还是权限问题。
建议按以下顺序完成首次部署。
第 1 步：确认系统、运行时和网络条件
在云端 Mac 上先确认：
sw_vers
node --version
git --version
Claude Code 官方安装文档要求 macOS、Node.js 18 或更高版本，并明确说明认证和 AI 处理需要互联网连接。不要依据来源不明的一键脚本判断系统是否合适；优先使用官方安装方式，并在安装后执行：
claude doctor
官方文档同时提醒，不要使用 sudo npm install -g，因为这可能导致权限问题和安全风险。
| 检查项 | 通过条件 | 未通过时的动作 |
|---|---|---|
| macOS | 符合 Claude Code 官方支持范围 | 先更换或升级主机 |
| Node.js | 18 或更高版本 | 通过正式安装方式更新 |
| 网络出口 | 能完成登录并访问服务 | 检查防火墙、代理或网络限制 |
| 项目目录 | 代码已恢复且路径明确 | 不要直接复制整个旧用户目录 |
| Git 状态 | 分支、远程仓库和提交记录可确认 | 先修复版本控制，再启动代理 |
如果你需要先了解可用的 Mac 形态，可以查看 云端 Mac 工作站方案，但具体配置、交付方式和租赁周期应以当期页面为准，不要把博客中的通用判断当成固定套餐承诺。
第 2 步：只恢复当前项目需要的内容
优先恢复 4 类内容：
- 代码仓库和指定分支。
- 项目要求的运行时、包管理器和依赖锁文件。
- 测试命令、构建命令和部署脚本。
- 项目文档、环境变量模板和回滚说明。
不要先恢复生产密钥。先用测试账户或最小权限凭据验证流程，再决定哪些密钥需要进入云端环境。
你的目标不是“把旧 Mac 复刻出来”，而是让另一个设备能在几分钟内确认 3 件事：代码在哪里、怎样运行测试、怎样判断任务完成。
第 3 步：安装并验证 Claude Code
官方文档给出的标准安装方式是：
npm install -g @anthropic-ai/claude-code
安装完成后进入项目目录，启动 Claude Code：
cd your-project
claude
登录方式包括 Anthropic Console、Claude 应用的订阅方案，以及企业平台集成。身份验证完成后，再运行一次 claude doctor，确认安装类型和版本状态。Claude Code 支持自动更新：启动时和运行期间会检查更新，更新通常在后台下载，并在下次启动时生效。
这意味着你不能只在出发前“登录一次”就结束验收。第一次更新后，要重新检查项目路径、插件、MCP 配置和测试命令是否仍然可用。
第 4 步：配置远程入口，而不是只依赖图形桌面
至少准备两条入口：
- SSH：适合启动任务、查看日志、确认 Git 状态和恢复终端。
- VNC 或受控桌面：适合处理需要图形界面的 macOS 工具、登录窗口和视觉检查。
Apple 官方文档说明，开启“远程登录”后，可以使用 SSH 或 SFTP 访问 Mac；同时可以选择允许所有用户，或限制为指定账户。Apple 也特别提醒，开启远程登录可能降低安全性，因此不要默认开放给所有账户。(Apple 远程登录官方文档)
如果使用屏幕共享，Apple 的设置允许你限制可访问用户，也可以开启 VNC 用户控制屏幕。屏幕共享能够打开、移动和关闭窗口，甚至重启 Mac，因此它不是“只看不改”的观察工具。(Apple 屏幕共享官方文档)
| 入口 | 适合做什么 | 主要风险 | 备用方式 |
|---|---|---|---|
| SSH | 运行命令、查看日志、恢复会话 | 终端环境变量或密钥配置错误 | 受控桌面 |
| VNC / 屏幕共享 | 使用图形界面和 macOS 应用 | 延迟、画面中断、权限过宽 | SSH |
| 网页控制台 | 快速进入主机、处理入口切换 | 依赖服务商控制台可用性 | SSH 或 VNC |
| 本地终端 | 无网络时编辑和提交代码 | 环境可能不完整 | 云端 Mac |
首次委派任务：先验证代理边界，再运行长任务
第一次不要直接让 Claude Code 修改整个项目。先给一个低风险任务，例如：
- 阅读项目结构，不修改文件；
- 执行已有测试并解释失败原因；
- 生成变更计划，但不自动写入；
- 检查
git diff，确认当前工作区没有意外改动。
Claude Code CLI 官方参考中提供了 --permission-mode plan、--allowedTools、--disallowedTools、--max-turns 等选项，可分别用于计划模式、允许或禁止特定工具，以及限制非交互任务的代理轮数。官方同时将 --dangerously-skip-permissions 标注为谨慎使用的选项。(Claude Code CLI 官方参考)
云端 Mac 使用 Claude Code 应开放哪些权限
权限应按任务拆开，不要为了省掉确认提示就一次性放开所有操作。
建议采用 3 层：
- 观察层：允许读取文件、搜索代码、查看 Git 日志和差异。
- 修改层：只允许当前项目目录内编辑，禁止访问无关目录。
- 执行层：只开放项目测试、格式化和构建命令；涉及部署、删除、密钥读取的命令保留人工确认。
Anthropic 的权限文档说明，权限规则可以来自 settings.json，拒绝规则优先于允许规则；官方示例还区分了标准模式、自动接受编辑、计划模式和绕过权限提示的模式。(Claude Code 权限与身份管理文档)
Apple 侧也要限制远程账户。远程登录设置中可以选择“仅这些用户”，并单独决定是否允许远程用户获得完整磁盘访问。完整磁盘访问不是远程开发的默认必需项，只有在明确知道某项工具需要时才应考虑开启。
给长任务写出完成证据和停止条件
每次委派前，写清楚以下内容：
- 输入：任务涉及哪个分支、哪个目录和哪些文件。
- 完成证据：测试命令通过、变更文件列表符合预期、Git 差异可审查。
- 检查点：完成计划、第一次修改、测试通过后分别暂停。
- 停止条件：出现依赖安装失败、生产凭据请求、删除操作或连续测试失败时立即停止。
- 恢复动作：停止后保留日志、提交临时分支或回滚到上一个可用提交。
这样做的意义是：你在飞机、地铁或网络不稳定的咖啡馆里暂时离线时，代理不会因为缺少人工确认而无边界扩大操作范围。
跨设备切换：Claude Code 可以在云端 Mac 上继续吗
可以把 Claude Code 安装在云端 Mac 上，但“安装成功”不等于“任何断线都能自动继续”。官方文档确认，CLI 支持使用 claude --continue 继续当前目录最近一次会话，也支持通过会话 ID 使用 claude --resume 恢复指定会话。(Claude Code 会话与命令行用法)
这里有一个关键边界：会话恢复依赖云端 Mac 上的项目目录、会话信息和代码状态仍然存在。你不能把“iPad 上的终端窗口断开”简单理解成“云端任务一定还在运行”，也不能把“重新登录后能看到项目”理解成“任务已经完成”。
推荐这样验证：
pwd
git status --short
claude --continue
如果你保存了会话 ID，再使用：
claude --resume "<session-id>"
恢复后先不要继续下新指令。先查看：
git diff
git log -1 --oneline
再检查测试日志和任务输出。你要确认的是“实际变更状态”，而不是只看终端里最后一行文字。
断线演练：分别测试 SSH、桌面和主机状态
数字游民真正需要的是恢复能力，而不是一次顺利连接。出发前至少做一次主动演练：启动一个不会修改生产数据的任务，然后切换 Wi-Fi、让 iPad 休眠，再从另一台设备重新连接。
iPad 断线后，任务会不会中断
答案不能一概而论。若只是 iPad 上的 SSH 或远程桌面窗口断开，云端 Mac 上的进程是否继续，取决于任务如何启动、终端会话是否保持，以及主机本身是否仍在线。官方文档提供的是会话继续和恢复命令，不是对所有第三方终端、VNC 客户端或网络环境下“持续运行”的保证。
因此，测试时分开记录 3 种结果：
| 断线类型 | 重新连接后先看什么 | 结果判断 |
|---|---|---|
| 只有 SSH 窗口断开 | 进程、日志、Git 状态 | 任务可能仍在，需人工核验 |
| 远程桌面不可用 | SSH 是否还能进入 | 能进 SSH，优先走终端恢复 |
| 云端主机无法访问 | 控制台状态、重启记录 | 先确认主机状态，再判断任务是否可恢复 |
如果任务需要持续运行，不要只在交互式窗口里启动后就离开。你至少要准备日志输出、阶段性提交或可重复执行的命令。对于高风险任务，宁可让 Claude Code 在检查点停住，也不要把所有权限和完成判断都交给无人值守流程。
远程检查任务状态的最小流程
远程查看状态时，优先从最小信息开始：
- 连接 SSH，确认主机可达。
- 进入项目目录，确认当前分支。
- 查看
git status和最近提交。 - 检查任务日志或终端会话。
- 使用
claude --continue或会话 ID 恢复上下文。 - 重新运行测试，再决定是否继续修改。
如果 SSH 可用但桌面不可用，说明图形入口出问题，不一定代表代码任务失败。相反，如果 SSH 和桌面都不可用，就不要反复刷新客户端，应转向主机状态、网络入口和凭据撤销检查。
设备遗失时，第一动作不是从新设备登录，而是撤销旧设备保存的 SSH 密钥、远程桌面凭据和控制台会话。然后再从可信设备登录，并检查最近的代码变更。
如果你准备在亚洲旅途中使用，可先查看 新加坡云端 Mac 节点 或 东京云端 Mac 节点 的当期信息。地域选择只能作为连接路径的实际测试项，不能直接等同于某个固定延迟或持续在线承诺。
首周维护：用记录决定是否长期迁移
首周不要只记录“今天能不能连上”。你需要记录每个旅居地点的连接表现、切换网络后的恢复结果，以及 Claude Code 更新后项目是否仍能正常运行。
建议建立一张简单的周记录表：
| 记录项 | 每次换地点都检查 | 影响的决策 |
|---|---|---|
| Wi-Fi 切换后能否重新连接 | 是 | 是否保留云端主环境 |
| SSH 与远程桌面是否都可用 | 是 | 是否需要双入口 |
| 项目测试和构建是否通过 | 是 | 是否能继续交付 |
| 依赖和存储增长 | 每周 | 是否需要调整环境 |
| 密钥、备份和权限变更 | 每周 | 是否适合处理敏感项目 |
| Claude Code 更新后的行为 | 更新后 | 是否暂停自动迁移 |
Claude Code 官方文档说明，自动更新会在启动和运行期间检查，并在后台安装；你也可以使用 claude update 手动更新。更新机制变化时，首周维护应重新执行 claude doctor、登录检查和项目测试。
网络受限时，还要检查代理和出口策略。Anthropic 官方文档列出了 Claude Code 需要访问的服务地址，并说明支持标准 HTTP / HTTPS 代理，但不支持 SOCKS 代理；不要把含密码的代理地址硬编码进脚本。(Claude Code 企业代理配置文档)
成本判断也放在首周之后。按周、月还是季使用，应由真实旅行周期、项目交付周期和维护负担决定。短期项目先按较短周期验证；只有连续多个项目都能稳定恢复，才适合延长周期。不要使用没有当期页面或账单依据的固定金额，去计算所谓“回本时间”。
最终选择：本地 MacBook、云端 Mac，还是双轨
你可以按下面的结果做最后判断：
- 若满足 macOS 工具链依赖、频繁跨设备、网络基本可用，且任务可以通过检查点审查，则选云端 Mac。
- 若满足长期离线、必须使用物理接口、需要本地授权或经常处理无网络数据，则保留本地 MacBook 或完整本地环境。
- 若满足高风险交付、跨国移动频繁、又不能承受环境重建，则选双轨：云端 Mac 作为主环境，本地设备保留最小可交付能力。
- 若连续一周仍无法在换网后确认任务状态，或每次都需要手动重建依赖，则暂停迁移，不要急着把本地环境删掉。
本地方案的缺点是设备重量、丢失或损坏后的恢复成本，以及换设备后重新配置 macOS、运行时和密钥的时间。普通云主机的缺点是未必提供你项目需要的 macOS 工具链，图形桌面和 Apple 平台开发流程也可能不完整。只依赖随身 iPad 或轻薄本，则会把终端会话、网络稳定性和任务连续性绑在同一台设备上。
如果你已经遇到“换一次网络就丢上下文”“换一台设备就要重装环境”这两类问题，比较稳妥的做法不是立刻放弃本地设备，而是先通过 MACCOME 租用一台云端 Mac，拿真实项目完成一次断线、SSH 恢复、桌面重连和权限复核。测试通过后，再根据旅行周期决定采用云端主环境，还是保留本地与云端并行的双轨工作流。