Claude Code fork 会建 worktree 吗
v2.1.224 起 /fork 复制会话并在独立 git worktree 改码，与 Cursor worktree 入口不同，附隔离边界。
你在主 checkout 上跑 refactor，又想并行试另一套方案。claude code fork 会建 worktree 吗？从 v2.1.224（2026 年 8 月第 32 周 changelog）起，用 /fork 复制的会话会在自己的 git worktree 里改文件，不再和原会话共用同一工作目录。
/fork 复制的是什么
/fork 从当前交互会话分出一支独立会话：对话上下文、工具权限、插件状态按 fork 规则继承，但代码改动目标换成新 worktree。Week 32 的 Other wins 写得很直白：「A session you copy with /fork now makes its code changes in a worktree of its own instead of the original session's checkout.」
这和「新开一个终端、cd 到同一目录再跑 claude」不同。后者两个会话仍争用同一 git index；fork 后的子会话在独立 checkout 上读写，主会话 checkout 里的未提交改动不会被 fork 侧直接覆盖。若你只想复制聊天、不动文件树，应查 resume 或导出 transcript，而不是 fork。
fork 会话仍受同一仓库的 Claude Code 设置约束：.claude/settings.json、hooks、CLAUDE.md 层级照旧加载；变的是物理路径。两个 fork 并行时，各自 worktree 的 node_modules、构建缓存、本地 .env 不会自动同步，需要在 .cursor/worktrees.json 那类 setup 脚本里单独处理，Cursor 侧做法见 cursor worktree 怎么用。
与 Cursor worktree 怎么区分
名字都叫 worktree，入口和生命周期不一样。Cursor 在 Agents Window 或 IDE 里用 /worktree、/best-of-n 给 Agent 建隔离 checkout，文档强调 UI 原生 worktree 只在 Agents Window 可用。Claude Code 的 worktree 绑定在终端会话 fork 上：你在 TUI 里 /fork，Anthropic CLI 为 fork 会话分配 worktree，不经过 Cursor 的 worktrees.json（除非你在 Cursor 内置终端里跑 Claude Code，那时两套工具可能同机并存，但彼此不自动关联）。
对照表（只比「谁建 worktree、为了什么」）：
| 维度 | Claude Code /fork | Cursor /worktree |
|---|---|---|
| 触发 | 复制当前 Claude 会话 | Agent 任务或 best-of-n 对比 |
| 主要目的 | 同一思路下并行试改、互不踩文件 | 多模型/多 Agent 并行实验 |
| 典型用户 | Claude Code CLI 终端重度用户 | Cursor Agents Window / IDE |
Claude Code 同版 changelog 还加强了 worktree 隔离：不仅文件编辑，连 Bash 与 git redirect 若试图碰主 checkout 也会被挡，subagent 同样受约束。Cursor 文档则侧重 setup 脚本与清理上限。两边都追求「并行不脏主树」，但 Claude Code 把 fork 和 worktree 写进一条会话复制路径里。
若你在 fork 里跑 git worktree list，应能看到主 checkout 与 fork 条目并列；subagent 在 fork 会话内 spawn 时，同样不能通过 shell 技巧把改动写回主树。Week 32 还修了「Bash 命令不能把一部分藏起来绕过 permission check」类漏洞，与 worktree 隔离同属 hardening，部署后值得用一次故意 git -C ../main 的探针确认被拦。
和跨会话消息、后台 session 的关系
fork 解决的是文件树隔离；Claude Code 跨会话发消息 解决的是会话间传话。你可以 fork 后在 worktree A 改 schema，用 SendMessage 告诉仍在主 checkout 的会话 B「字段已 rename」，两者互补。SendMessage 不传文件、不传完整历史，只传 Claude 写给对方 Claude 的短文本。
Week 32 另一条相关变更：在 worktree 里改完代码的 background session，结束时会 commit 并 push，仅在任务需要时开 draft PR，并遵循 CLAUDE.md 里的 git 说明。fork 出的 worktree 若跑长任务，结束行为与 background session 规则一致，比早期「worktree 里改完就丢」更可审计。若 fork 侧要通知主会话「已 push 哪条分支」，SendMessage 比手动复制 git log 更省事。
实操上怎么开、怎么收尾
交互会话里执行 /fork（子命令名以 v2.1.224+ 内置帮助为准）。fork 完成后，状态栏或 /status 应显示 worktree 路径；在该会话里让 Claude 改文件，diff 只落在 fork 的 checkout。主会话继续盯原目录，两边可同时跑测试，注意端口与环境变量冲突。
收尾常见三条路：在 fork worktree 里 commit 并 push 开 PR；把改动 cherry-pick 回主 checkout；或删除 fork 会话与对应 worktree。Claude Code 没有 Cursor 的 /apply-worktree 命令名，合回主树通常靠 git 工作流（merge、cherry-pick）或你在主会话里口述让 Claude 读 fork 分支 diff。删除孤立 worktree 前用 git worktree list 确认路径，避免留下 .git/worktrees 垃圾条目。
fork 会话里的插件与 MCP 配置继承自主会话，但各 worktree 的 .env 不会自动复制。若 setup 依赖主 checkout 的环境文件，在 fork 侧第一次跑测试前手动 cp 或写进 CLAUDE.md 提醒 agent 检查 $ROOT 路径。Background session 在 worktree 完成后的 auto push 行为，取决于任务描述是否要求 PR；纯本地实验可明确说「不要 push」，避免 draft PR 污染远程。
若组织开了 Claude Code 自托管环境，cloud session 的 checkout 在 runner 上；fork/worktree 行为跟随 runner 镜像里的 CLI 版本，与本地终端同一套 changelog，但磁盘与并发受 runner capacity 限制，不宜在同一 runner 上无节制 fork 大量 worktree。
什么时候用 fork，什么时候别用
适合 fork：同一任务想试两种实现、主 checkout 必须保持可编译 baseline、需要 parallel 改不同模块且怕 merge 冲突。不适合 fork：只是想要第二个聊天窗口问文档（用新会话即可）；要把整段上下文搬到 Codex 或 Cursor（用 agent-hop 跨工具续会话 或 resume，不是 fork）；改动极小、单文件一行 fix（fork 的 worktree 创建成本不划算）。
Week 32 还移除了每会话 200 个 subagent 的上限，并发与深度限制仍在。fork 会话里大量开 subagent 做探索，磁盘与 API 用量仍可能爆，worktree 隔离救不了额度问题。升级前版本 fork 仍共用原 checkout，若团队混用版本，文档里应写清「v2.1.224+ 才自动建 worktree」。
同一仓库若同时开 Cursor Agents Window worktree 与 Claude Code fork worktree，磁盘上会出现多份 git worktree list 条目，互不自动清理。建议给实验性 fork 定命名约定，定期 git worktree prune，并在 CLAUDE.md 里写清「默认开发仍在 main checkout，fork 分支命名 exp/*」。CI 只监听 main 与 release 分支时，fork worktree 里的 WIP push 不会误触发生产部署，但仍应防 agent 把实验分支 push 成 default 可见名。