Claude Code 云端会话实战指南：并行任务、环境配置与分支交接
Claude Code in the cloud: a field guide to cloud sessions
Claude Code 云端会话指南通过实测讲解如何在独立虚拟机和分支中并行执行编码任务，并配置环境、验证结果及交接回本地。示例中，3 个会话在 16 秒内先后启动，全部在首次启动后 87 秒内完成；修复缓存竞态的会话连续运行测试 40 次，零失败。云端计算不单独收费，但会消耗套餐用量；各会话无法共享尚未合并的修复，个人 ~/.claude 配置也不会随仓库进入云端。
按文件边界拆分任务、明确验收命令并安排分支合并顺序，为并行编码提供了可迁移的方法，也解释了会话隔离为何不能消除任务依赖。
你大概是在自己笔记本电脑上的终端里运行 Claude Code。那个会话在三个方面依赖这台笔记本电脑：
- 它会共享你的工作树，所以同一仓库上的两个会话可能会编辑同样的文件，并争抢同一个端口。
- 它会使用你的凭证运行。
- 当你的电脑休眠或 Wi‑Fi 断开时，它就会停止。
云端会话会让 Claude Code 在一台属于它自己的机器上运行。每个任务都会获得一台全新的虚拟机，其中你的仓库会被克隆到一个新分支上，而且你环境中的设置也已事先完成。
你可以从 claude.ai/code、Claude 移动应用、桌面应用、你的 终端 和 Slack 启动它。然后你可以在浏览器、移动应用和桌面端继续跟进它。工作完成后，它会停留在一个分支上，你可以把它变成拉取请求。
云端会话包含在你的 Pro、Max、Team 或 Enterprise 套餐中，无需额外付费：云端机器不会单独收费，而且会话会与 Claude Code 的其他部分共用同样的使用限额。根据你的套餐，组织所有者可能需要先 开启云端会话。
为了撰写这份指南，我针对一个小型示例仓库运行了四个真实的云端会话。它们的转录、差异和耗时贯穿全文。仓库和截图中的用户都是虚构的。工作、输出和数字都来自这些会话。
云端会话的一个主要优势是，你可以同时运行多个任务，而不会让它们彼此碍事。下面是我在彼此相隔 16 秒内启动的三个任务，每个都运行在自己的机器上。要是在我的笔记本电脑上，我就得把这些任务一个接一个地运行，或者把时间花在防止它们互相干扰上。
三个任务，一个仓库，三台机器
这个示例仓库是 tidepool，一个用于预测三个虚构港口潮汐的小型 Node API。它有三个常见问题：有一个测试大约每四次运行就会失败一次，API 文档描述了代码已经不再读取的参数，而日志记录器则通过拼接字符串来构造日志行。
我在彼此相隔 16 秒内启动了三个云端会话，每个问题一个。我以编程方式启动了它们，而且由于 tidepool 不在 GitHub 上，每个会话首先都根据提示中的文件重新创建了这个仓库。如果是一个真实仓库，你就可以跳过这一步，而且在终端里，每个会话只需要一条 claude --cloud 命令。简化后，这三个提示是：
代码Shell
claude --cloud "npm test fails maybe one run in four. Find the flaky test, fix the root cause in the code (not the test), and prove it by running the suite at least 30 times in a row." claude --cloud "docs/API.md is out of date with src/server.js. Rewrite it so every endpoint, parameter, default and response shape matches the code. Start the server and run each curl example to check it." claude --cloud "Make src/logger.js emit one JSON object per line, keep LOG_LEVEL, and log method, path, status and duration_ms as fields. Add a test for the logger."
这些会话分别运行了 61、65 和 72 秒，而在第一个会话启动 87 秒后，三个会话全部完成。重新创建仓库大约占了每次运行的三分之一到略高于一半的时间。以下是结果。
- 这个不稳定的测试。 Claude 在
TtlCache.get中发现了一个竞态条件。缓存只有在加载器完成后才会存储一个值，因此在加载过程中，针对同一个键的第二次get会再次调用加载器。Claude 修改了缓存，让它存储正在进行中的 promise，在加载失败时删除该条目，并连续运行了npm test40 次，零失败。 - 文档。 Claude 启动了服务器，对每个端点都跑了 curl，并发现旧文档有五处错误。它列出了 API 实际从不返回的字段，记录了一个代码会忽略的
days参数，在本应以 metres 表示的地方写成了 feet，跳过了/next-high端点，还遗漏了错误响应。它还发现格式错误的from=值会返回一个空列表和 200 状态码，并把这点记成注意事项，而不是去改动它没有被要求修改的服务器代码。 - 日志记录器。 Claude 编写了 JSON 日志记录器，把请求日志迁移到了结构化字段里，并新增了五个测试。它的提交带着一个失败的测试被合入，于是 Claude 把缓存测试重跑了八次，发现其中五次失败，并将失败追踪到第一个会话正在修复的同一个竞态问题。它提出了同样的修复方案，没有动缓存，因为那超出了它的任务范围，并在总结里说明测试套件并不干净。
日志记录器的结果说明了为什么云端会话适合并行工作。每个会话都有自己的代码仓库副本、自己的进程和自己的分支。文档会话和日志记录器会话都各自启动了 API 服务器来对其进行测试，而且彼此互不影响。在一台笔记本电脑上，如果两个 agents 在同一个 checkout 里工作，就会编辑同样的文件；除非它们各自选择不同的端口，否则还会在端口上发生冲突。
正因为这种隔离，日志记录器会话无法访问第一个会话正在进行的缓存修复。把并行任务按文件边界拆分，以合理的顺序合并各个分支，并要预期某个会话会报告另一个会话已经在修复的问题。
CLAUDE CODE 云端会话的内部机制
云端会话是在 Anthropic 管理的基础设施上运行的 Claude Code 会话，或者运行在你所在组织自有机器上的 自托管环境 中。图中展示了它的组成部分。后面的四点结论，才是会改变你工作方式的部分。
- 每个任务都有自己的机器。 一个全新的 VM，你的代码仓库会被克隆到一个新分支上，因此各个会话无法碰到彼此的文件或端口。参见 已安装的内容。
- 你的 GitHub token 永远不会进入 VM。 它由一个代理持有，而会话拿到的是一个短期凭证，只能 push 到它自己的工作分支。参见 GitHub 代理。
- 代码仓库的 Claude 配置会一并带上，而你的个人配置不会。
CLAUDE.md、规则、skills、agents 和 commands 会随仓库一起走，而你的~/.claude会留在你的笔记本电脑上。参见 云端会话中的设置。 - 空闲的 VM 会被回收。 重新打开会话时，你会得到一台恢复了对话的新 VM，所以把你在意的工作提交掉。参见 环境过期。
本地还是云端？
云端会话并不会取代本地会话，大多数人两者都会用。表格展示了它们的区别，后面的段落则说明了各自适合在什么时候使用。
| 本地会话 | 云端会话 | |
|---|---|---|
| 运行位置 | 你的机器 | 每个任务一台全新的 VM |
| 笔记本电脑休眠或离线 | 会话会停止 | 会话会继续运行 |
| 一个代码仓库上的多个任务 | 分开的 worktree、端口和维护成本 | 每个任务一个 VM 和一个分支 |
| Agent 能访问什么 | 你的用户账户能访问的任何东西，包括 SSH 密钥、云 CLI 和 ~/.claude | 仓库、你设置的网络级别、你启用的连接器，以及一个会话范围的 GitHub 凭证 |
| 开始或跟进的方式 | 那台机器，或者通过远程控制用你的手机 | 浏览器、手机、Desktop、终端、Slack、一次 API 调用或一个计划任务 |
| 审批 | 任何模式，包括逐命令审批 | 自动、接受编辑或计划 |
| 结束时得到 | 你工作树中的更改 | 一个分支，以及在你需要时的一个 pull request |
| 算力 | 你的机器 | 没有单独的算力费用；使用你的套餐额度 |
当任务需要只有你的机器才有的东西时，就留在本地。这包括带有真实本地数据的数据库、你通过 VPN 访问的服务、GPU、手机模拟器，或你桌上的硬件。对于那种紧密的可视化循环——你希望在几秒内就在自己的浏览器里看到每次改动——以及当你的组织启用了 Zero Data Retention，这会关闭云会话时，也应留在本地。
有两个功能介于这两种选项之间。Remote control 让会话留在你的机器上，并允许你通过手机或浏览器来操控它。面向 Team 和 Enterprise、目前处于 beta 的 Self-hosted environments 会在你组织自己的基础设施上运行云会话，因此它们可以访问私有网络。
如果这些情况都不适用，那么这个任务就很适合放到云端。下一节会介绍最能体现这种收益的工作流。
适合云会话的七种工作流
这些工作流把表格中的差异真正利用了起来：每个任务一台独立机器、在你离开时仍持续运行的会话，以及最后供你审查的一个分支。
1. 并行清理积压任务
假设你有五个小而互不相关的修复。在本地，你会一个接一个地做，或者搭建五个 worktree，并让它们的端口和安装彼此分开。在云端，你会启动五个会话并审查五个分支。
代码Shell
claude --cloud "Fix the flaky test in auth.spec.ts" claude --cloud "Update the API documentation" claude --cloud "Refactor the logger to use structured output"
claude --cloud 会在你当前分支上克隆你的 GitHub 远程仓库，所以请先推送你的本地提交。在 VM 启动期间，CLI 会显示一份实时的设置步骤清单，并把你输入的任何内容排队。
把每个任务都写成一张自包含的工单，说明哪里有问题、完成后是什么样子，以及如何证明它已经完成。那个 flaky-test 提示词点明了它的证明方式：连续至少运行 30 次测试套件。该会话实际跑了 40 次。
当这些任务属于同一个更大项目时，project（面向 Pro 和 Max 的公开 beta）会运行一段协调对话，替你启动并跟踪这些云会话。然后它会按状态对它们分组：进行中、等待你处理，以及准备好供审查。
2. 让它证明修复有效
不稳定测试是最典型的那类需要反复证明的工作：你必须一遍又一遍地运行测试套件，而你又不希望这个循环占着你正在使用的机器。在云端，Claude 修补了缓存，并用一条命令把整个测试套件跑了 40 次。
VM 没有单独的算力费用，而且它的 CPU 也不是你的，所以尽管要求它给出充分的证明。把测试套件跑 200 次，在 50 个提交之间二分定位一次回归，运行缓慢的集成测试层，或者像 docs 会话那样启动应用并用 curl 去打它。
Claude 的每一轮回复仍然会计入你的套餐，但在一条命令里进行一次长时间测试运行几乎不怎么花费。前台命令默认会在 2 分钟后超时（最长 10 分钟），随后会继续在后台运行最多 30 分钟。你可以用环境变量中的 BASH_DEFAULT_TIMEOUT_MS 和 BASH_MAX_TIMEOUT_MS 提高这些默认值。
3. 在桌前规划，在云端构建，在终端完成
对于较大的改动，先就方案达成一致，因为在那里来回沟通的成本更低。以规划模式启动 Claude，一起敲定计划，提交计划，然后推送它。
CODEShell
claude --permission-mode plan # ...agree on the plan, save it to docs/migration-plan.md, commit and push... claude --cloud "Execute the migration plan in docs/migration-plan.md"
在云端会话构建期间，你的终端可以空出来做别的工作。完成后，把该会话拉取下来，手动把收尾工作做完。
CODEShell
claude --teleport # pick a cloud session claude --teleport <session-id>
Teleport 会检查你是否位于同一个代码仓库，获取该会话的分支，切换到它，并将整个对话加载到你的终端中。你需要一个干净的工作树（它会提供 stash 选项），而且这个分支必须已经被推送。在 Claude Code 中，/teleport（或 /tp）会打开同一个选择器，而 /tasks 然后 t 也能实现同样操作。Desktop 应用则是反向操作，它的 Open in 菜单会把本地会话发送到云端。
4. 用手机跟进
Claude 应用中的 Code 标签页会连接到同样的会话。你可以在手机上启动任务、跟进进度、引导它、回答 Claude 提出的问题，或者让 Claude 监视一个拉取请求。
手机很适合处理那些等你走到键盘前可能就忘了的问题。我给第四个会话提了一个你会在手机上输入的问题：tidepool 是如何预测潮汐的，它又会如何在时间窗口的边界出错？它运行代码来验证自己的答案，并发现了一个真实的 bug。这个循环从不检查第一个或最后一个采样点，所以 API 会漏掉恰好落在窗口起始位置的高潮。
5. 把 CI 失败和审查评论交给 Claude
在某个仓库安装了 Claude GitHub App 后，云端会话就可以监视一个拉取请求，并对其变化作出处理。在 claude.ai/code 的会话中，前往 CI 栏并开启 自动修复。你也可以在终端的 PR 分支上运行 /autofix-pr，让移动应用监视这个 PR，或者把 PR URL 粘贴到一个会话里。
Claude 会为失败的检查项和审查评论推送清晰的修复，并解释它改了什么。对于任何有歧义或涉及架构的问题，它都会询问你。审查线程中的回复会以你的 GitHub 用户名发布，并标记为 Claude Code。Claude 不会收到与基线分支发生合并冲突的通知，所以你要让它执行 rebase。它的评论还可以触发由评论驱动的自动化流程，例如 Atlantis。
6. 不必亲自开始，也能启动工作
routine（研究预览）是一组为完成某项任务而设计的已保存资源，例如提示词、代码仓库、连接器和环境。每次运行都是一个云端会话，由触发器启动。触发器可以是一个计划任务（最频繁可达每小时一次）、对该 routine 自身端点发起的 HTTP 调用，或者诸如拉取请求开启或发布版本之类的 GitHub 事件。你可以在 claude.ai/code/routines、Desktop 应用中，或通过 CLI 中的 /schedule 创建它。Routines 运行时不会出现批准提示，而且默认会推送到带有 claude/ 前缀的分支。
这里还有两个更小的工具可以提供帮助。你可以在任何已登录的设备上，把后续任务排进一个正在运行的会话里，包括 CI 作业。
CODEShell
claude -p "The integration tier is green now; rebase on main and push" --cloud <session-id>
你还可以为一个预填好的会话加书签。像 claude.ai/code?prompt=Triage+the+newest+issues&repositories=acme-labs/tidepool 这样的 URL 会打开 claude.ai/code，并且其中的提示词和代码仓库都已预先填好。
7. 运行你并不完全信任的代码
贡献者的 pull request、新依赖的安装脚本，或你五分钟前刚克隆的仓库，都可能运行你还没读过的代码。在你的笔记本上，这些代码会与你的 SSH 密钥、云端 CLI 会话和浏览器配置文件并排运行。在云端会话中，它运行在一个一次性 VM 里，没有这些东西，只有一个会话作用域的 GitHub 凭证，以及一个你可以收窄的网络。
将环境的网络访问设为 None 可获得最严格的运行方式，或者保留 Trusted，它允许访问包注册表、GitHub 和主要的云 SDK 主机。即使设为 None，Claude Code 仍会向 Anthropic API 发送请求，因此数据仍可通过这种方式离开 VM，而且该会话仍然可以推送到它自己的分支。所有出站流量都会经过一个记录主机名的代理。
顺利连接 GitHub，不要卡住
如果你的第一次云端会话出了问题，最可能的原因是 GitHub。大多数问题都源于云端会话需要两项独立的 GitHub 权限。
- 使用 GitHub 登录会告诉 Claude 你是谁。
- 在某个账户或组织上安装 Claude GitHub App会决定 Claude 在那里能看到哪些私有仓库。
公开仓库只靠第一项就能使用。私有仓库需要第二项，并且要安装在拥有这些仓库的账户或组织上。如果你已经连接了 GitHub，但某个私有仓库没有显示，通常是因为 App 没有安装在拥有它的账户或组织上。
| 你已连接的内容 | 公开仓库 | 你的私有仓库 | 某个组织的私有仓库 | 自动修复、GitHub 触发器、项目 |
|---|---|---|---|---|
| 仅使用 GitHub 登录 | 是 | 否 | 否 | 否 |
| + 在你的个人账户上安装 App | 是 | 是 | 否 | 你的仓库 |
| + 在该组织上安装 App（需所有者批准） | 是 | 仅当你的账户上也安装了时才可以 | 是 | 组织仓库 |
/web-setup (你的 gh token) | 是 | 是 | 你的 token 能访问到的任何内容 | 不行，需要 App |
路径 A：在浏览器中连接（推荐）
在 claude.ai/connect-github 连接你的 GitHub 账户，然后在拥有你的仓库的账户或组织上安装 Claude GitHub App。对于组织，通常需要由所有者批准安装。quickstart 会带你完成每一步。
如果 GitHub 没有把你带回 claude.ai/code，claude.ai/connect-github 上的连接页面会显示一份简短清单，列出常见原因。其中之一是单点登录步骤，如果你跳过它，就会看不到某个组织的仓库。
自动修复、GitHub 触发的例程和项目也依赖 App，所以即使你用其他方式连接，也要安装它。
路径 B：在终端里通过 /web-setup 连接
如果你已经在使用 gh CLI，就在 Claude Code 里运行 /web-setup，把你的 gh token 发送到你的 Claude 账户。这样一来，无论有没有 App，会话都可以访问该 token 能访问的任何仓库。步骤说明见 Connect from your terminal。在 Team 和 Enterprise 方案中，所有者必须先开启 Quick setup。
路径 C：为一次性使用跳过 GitHub
在一个没有 GitHub remote 的仓库里运行 claude --cloud，或者在一个没有安装 App 的仓库里运行它，Claude Code 就会上传你的仓库打包文件，而不是去克隆它。只有当你的 GitHub 连接对该仓库具有推送权限时，会话才能推送回去。文档列出了 这个打包文件包含什么、不包含什么。
如果你使用 Team 或 Enterprise
所有者有一份简短的检查清单：在 claude.ai/admin-settings/connectors 打开 GitHub 连接器，在 Claude Code admin settings 中允许云会话，在组织的仓库上安装 Claude GitHub App（或批准成员的请求），并决定是否打开 Quick setup。使用 IP allowlists 或 GitHub Enterprise Server 的组织还需要额外一步。请参阅关于 IP allowlists 和 GitHub Enterprise Server 的文档。
当它仍然无法工作时
| 你会看到什么 | 原因 | 解决方法 |
|---|---|---|
| 私有仓库没有出现在选择器中 | 拥有该仓库的账户或组织上没有安装该 App，或者它的仓库访问范围不包含该仓库 | 在那里安装该 App，或者在你的 GitHub 设置中将该仓库添加到该 App 的 Repository access |
| 一条错误信息称你必须是该组织的所有者才能链接它 | 该组织阻止了成员身份检查，通常是因为有待处理的 App 权限请求、IP allow list，或 SAML 单点登录 | 由所有者在该组织的 GitHub App 设置中接受待处理的权限请求，为已安装的 GitHub App 打开 IP allow list 继承，或者（在 SAML 下）授予 Claude 对该组织的访问权限 |
| 你连接后，一个组织的仓库立即消失了 | 该组织使用 SAML 单点登录，而且其授权步骤被跳过了 | 在 GitHub 的“Single sign-on to your organizations”步骤中，继续之前，点击每个组织旁边的 Authorize。如果你已经跳过了它，请在你的 GitHub 设置中为该组织授权 Claude，然后重新连接 |
| 每个云会话都因身份验证错误而失败 | 你的 Claude 组织使用 IP allowlisting | 请支持团队将 Anthropic 托管的服务加入豁免 |
其他任何情况，请参阅文档中的 troubleshooting，包括 no repositories appearing after you connect GitHub。如果要彻底断开 GitHub，请使用 claude.ai/customize/connectors。
让会话获得检查自己工作的所需条件
能运行你的测试的会话，会在交还工作之前先检查自己的工作。否则，你审查的就是没人运行过的更改。本指南演示中的大部分价值，都来自 Claude 自己运行各种内容：套件跑了 40 次，服务器及其 curl 请求，还有在窗口边缘进行的潮汐计算。花十分钟做环境设置，就能让 Claude 有办法运行这些检查。
- 从 Default 环境开始。它使用 Trusted 网络访问、没有变量，也没有设置脚本，这对大多数 JavaScript、Python、Go 和 Rust 仓库来说已经足够。
- 为机器使用设置脚本。它会在 Claude Code 启动前以 root 身份运行，因此
apt install可以工作。它必须以退出码 0 结束，否则会话将无法启动；并且它应在大约五分钟内完成，这样环境才能被缓存。之后，新会话会从一个磁盘上已带有你的工具的快照启动。当你更改脚本或允许的主机时，缓存会重建，并且大约每七天也会重建一次。 - 为项目使用 SessionStart hook。把
npm install和类似步骤放进仓库的.claude/settings.json中的 hook 里，这样它们在本地和云端都会以相同方式运行。如果某个步骤只应在云端运行，请检查CLAUDE_CODE_REMOTE。仓库 hook 会在单仓库会话中加载。 - 按每个会话启动服务。 缓存会存储文件。之前运行的进程不会在其中保留下来。让 Claude 运行
service postgresql start，或者在 SessionStart hook 中执行它。 - 选择能用的最窄网络级别。 Trusted 覆盖常见的 registry。用 Custom 添加私有 registry，只有当任务需要开放互联网时才使用 Full。更改大约会在一分钟内传达到正在运行的会话。
- 不要把密钥放进共享变量。 环境变量对任何使用该环境的人都可见。在 Pro 和 Max 中，环境的 API 凭证会在 VM 外部，把密钥附加到发往你指定主机的请求上，因此密钥永远不会存放在变量里。
- 把命令写进 CLAUDE.md。 你的个人
~/.claude不会进入云端 VM。如果 Claude 需要知道如何运行集成测试，代码仓库里就必须写明。
这些习惯很有回报
- 一个任务，一个会话。 小而彼此独立的会话更容易审查，丢弃起来也更便宜。
- 索要证据。 说出能证明任务已完成的命令，并在看 diff 之前先读 Claude 的总结。
- 先 push，再
claude --cloud。 VM 是从 GitHub 克隆的，所以未 push 的提交不会到达它。 - 长任务要边做边提交。 空闲的 VM 可能会被回收。
- 在 diff 视图中审查。 行内评论会被批量加入你的下一条消息，而 Create PR 可以打开完整 PR、草稿 PR，或 GitHub 的撰写页面。
- 在 Claude 工作时继续引导。 你在 Claude 工作时发送的消息会排队，你也可以把已排队的消息撤回。
- 共享会话。 在 Team 和 Enterprise 中，把会话的可见性设为 Team，这样审查者就能看到变更是如何完成的。来自云端会话的提交会带有一个
Claude-Sessiontrailer，链接回这段记录。 - 留意你的限额。 并行会话会并行消耗你的套餐限额，所以五个会话的消耗速度大约是一个的五倍。Routines 也有各自的每小时上限，而 projects 每天最多可以启动 200 个新线程。
常见问题
谁可以使用云端会话？ Pro、Max 和 Team 套餐用户，以及拥有 premium seat 或 Chat + Claude Code seat 并使用 claude.ai 账户登录的 Enterprise 用户。它们不支持使用 Console API key 或第三方提供商。参见 云端会话文档。
我的数据会去哪里？ Anthropic 会存储会话记录，其保留时长取决于你的套餐和模型改进设置。VM 会在闲置后被回收，删除会话也会移除其数据。参见 数据使用 和 安全。
Claude 会用我的云端会话数据进行训练吗？ 云端会话遵循与 Claude Code 其余部分相同的政策。在 Team、Enterprise 和 API 中，除非你的组织选择加入，否则 Anthropic 不会用你的代码或提示词训练模型。在 Free、Pro 和 Max 中，这取决于你的 模型改进设置。参见 数据使用。
它能处理我的大型代码仓库吗？ 这台 VM 大约有 4 个 vCPU、16 GB 内存和 30 GB 磁盘。把较重的安装放进 设置脚本，这样它们只运行一次，并会进入缓存快照。
GitLab 或 Bitbucket 怎么样？ claude --cloud 可以从任何 git 仓库上传 bundle，但该会话无法向这些托管平台回推。 GitHub Enterprise Server 受 Team 和 Enterprise 支持。请参阅 平台限制。
并行分支发生冲突时会怎样？ 这些会话彼此不了解对方。先合并一个分支，然后 向下一个会话发送后续消息，例如 claude -p "rebase on main and fix any conflicts" --cloud <session-id>。
我会失去本地工具吗？ 用户级配置不会随之带过去，所以把团队需要的内容移到仓库里：将技能和命令提交到 .claude/ 下，把项目范围的 MCP 服务器添加到 .mcp.json，并在 CLAUDE.md 中记录测试命令。 云端会话中的设置 列出了每个会话会读取的内容。
五分钟即可开始
设置大约需要五分钟。之后，你就可以交接一个任务，合上笔记本电脑，回来时看到一个已准备好供审查的分支。
- 打开 claude.ai/code，或在 Claude Code 中使用你的 claude.ai 账户运行
/login。 - 连接 GitHub，并在你的仓库所在的位置安装 Claude GitHub App。
- 选择仓库和默认环境。
- 给 Claude 一个来自待办事项列表的任务，并附上一条能证明它已完成的命令。
- 关闭标签页。稍后用手机查看进展，然后在 claude.ai/code 审查 diff 并创建拉取请求。
来源：Claude Developer Blog · claude.dev