Canopy Canopy 在原生 macOS 上运行并行沙盒化的 Claude Code 会话，适合开发者管理多个 AI 编程任务，提高效率。 热门评论 PH 用户大家好 👋我是 Julien。我做了 Canopy，因为我每天都在用 Claude Code，有两个问题一直困扰我：避免并行任务的冲突，以及放心让智能体自己运行命令。Canopy 通过在两个层面做隔离来解决这些问题。每个任务在自己的 git worktree 里运行——独立的 branch、独立的目录——这样并行的 Claude 会话就不会互相踩文件。并且每个会话可以在沙箱容器里运行，无论是 Docker 还是苹果原生的 Container 框架，这样 Claude 就在受控的运行时里跑，而不是在机器上裸奔。代码层面用 worktree 隔离，容器层面让你安心。在此基础上，它全都集成在一个原生 macOS 窗口里——每个会话是一个标签页，Cmd+1–9 快速切换。关闭应用后每个会话恢复时对话完整保留，不用去找什么 session ID。还有一些从我日常烦心事出发的功能：→ Merge & Finish — 把五步的 merge 加清理操作简化成两次点击→ Split shell pane — 在不打断 Claude 的情况下跑 git 或 tail 日志→ Activity dashboard — 终于能看清你的 token 花在哪了原生 SwiftUI，没有 Electron，没有捆绑的 Node — 启动快，表现像 Mac 应用。免费开源，AGPL-3.0 协议。善意提醒：只支持 macOS，并且专门围绕 Claude Code 构建——不是通用的 worktree 管理器。它还年轻，主要经过我自己的工作流程考验。欢迎提交 bug 和反馈（很大一部分原因就是分享到这里来的）。PH 用户并行会话用 git worktree 做隔离——这个思路一旦看到就觉得太显然了，但我从没见过有人真这么干净地实现出来。不过真正打动我的是沙箱容器部分——让 Claude 自己跑命令，在容器里感觉安全得多。又一个 Windows 用户表示希望自己也能用上。PH 用户并行 Claude Code 会话的难点就是互相污染 git 状态和工作目录。如果每个会话能获得真正隔离的检出，那核心问题就解决了——剩下只是 UI 的事。PH 用户恭喜发布。worktree + 容器分离是最有用的部分：代码隔离和运行时隔离是两个不同的问题。有一个边界情况我想了解：当两个 Claude 会话触及共享项目表面，比如 package manifests、migrations、env 示例或生成的类型时，Merge & Finish 会在合并前检测跨 worktree 的冲突吗？还是工作流依然是“先合并一个，然后手动解决”？这个冲突边界正是让并行智能体不再感觉并行的地方。 热门产品Julien Simon2026-06-16原文 打开互动版
我是 Julien。我做了 Canopy，因为我每天都在用 Claude Code，有两个问题一直困扰我：避免并行任务的冲突，以及放心让智能体自己运行命令。
Canopy 通过在两个层面做隔离来解决这些问题。每个任务在自己的 git worktree 里运行——独立的 branch、独立的目录——这样并行的 Claude 会话就不会互相踩文件。并且每个会话可以在沙箱容器里运行，无论是 Docker 还是苹果原生的 Container 框架，这样 Claude 就在受控的运行时里跑，而不是在机器上裸奔。代码层面用 worktree 隔离，容器层面让你安心。
在此基础上，它全都集成在一个原生 macOS 窗口里——每个会话是一个标签页，Cmd+1–9 快速切换。关闭应用后每个会话恢复时对话完整保留，不用去找什么 session ID。还有一些从我日常烦心事出发的功能：
→ Merge & Finish — 把五步的 merge 加清理操作简化成两次点击
→ Split shell pane — 在不打断 Claude 的情况下跑 git 或 tail 日志
→ Activity dashboard — 终于能看清你的 token 花在哪了
原生 SwiftUI，没有 Electron，没有捆绑的 Node — 启动快，表现像 Mac 应用。免费开源，AGPL-3.0 协议。
善意提醒：只支持 macOS，并且专门围绕 Claude Code 构建——不是通用的 worktree 管理器。它还年轻，主要经过我自己的工作流程考验。欢迎提交 bug 和反馈（很大一部分原因就是分享到这里来的）。
有一个边界情况我想了解：当两个 Claude 会话触及共享项目表面，比如 package manifests、migrations、env 示例或生成的类型时，Merge & Finish 会在合并前检测跨 worktree 的冲突吗？还是工作流依然是“先合并一个，然后手动解决”？这个冲突边界正是让并行智能体不再感觉并行的地方。