让团队实时掌握 Claude Code 编码进展

让 Claude Code 在本地改代码，再把进展同步到 osFoundry 团队会话，是作者尝试的一种协作方式：开工先读邮件，过程中更新状态，到关键节点留下记录。团队负责人不用打开终端，也能看到任务推进到哪里、有什么问题需要回答。

这套方案的重点是把本地开发接进团队的信息流，同时限制消息、权限和数据的边界。不过，原文展示的修复代码、创建 PR 和团队回复都是模拟示例，不能当作完整跑通后的实测报告。

接通工具以后，还要给它一个能发言的席位

接入分两层：先让 Claude Code 连上 osFoundry，再授权它参与具体项目和会话。

下面这段展示了 CLI 如何打印连接命令，以及 Claude Code 使用的 MCP 地址：

$ osfoundry agent connect claude --print
$ claude mcp add --transport http -s user osfoundry https://api.osfoundry.io/api/v1/external-mcp

Sign in: open Claude Code, run /mcp, pick "osfoundry", Authenticate.

注意 --print 只是展示命令；后续还要执行连接，在 /mcp 中选择 osfoundry、完成 Authenticate，并在浏览器中选择工作区。连接后的工具以 mcp__osfoundry__ 为前缀。

接下来，在 osFoundry 的 Connected 面板选择 Claude Code，通过 Projects 中的 Add to project 加入目标项目。此时能看到项目内的会话，仍然不能写入。还要在「Agent, Team, and Loop sessions」中选择 Team session，指定会话并保存角色。

作者选择 Contributor，理由很直接：Viewer 只能读状态和邮件，Contributor 可以报告进展，Runner 还能发起 run。一个负责汇报的助手，没有必要同时拿到启动执行的权限。

进度不会自动出现，要把汇报时机写进规则

接通 MCP 不会让 Claude Code 主动写工作日志。作者建议把下面的约定放进仓库的 CLAUDE.md，解决何时读取信息、何时汇报以及如何结束的问题：

## osFoundry session
- This work is tracked in the osFoundry team session "Release desk".
- Before starting, read its mail (read_session_mail) and follow anything addressed to you.
- Keep set_status current: repo, branch, and a short task line. Clear all three when done.
- Post a note (post_session_note) when you start, when you need an answer, when the PR is up,
  and when you finish. Not after every edit.
- Use one idempotency_key per note, e.g. "cc-<branch>-<milestone>", and reuse it on retry.

这里要留意最后一行：每条笔记使用一个 idempotency_key，重试时复用，目的是避免一次汇报因重试变成多条重复消息。

汇报分成两种信息。set_status 保存 repo、branch 和 task，适合表达当前正在做什么；post_session_note 留下开工、求助、PR 就绪和完成等节点，供团队阅读。每次编辑都发一条，会把真正需要处理的信息淹没。

状态接口还有两个容易踩的细节。首次使用前，需要通过 claim_connected_profile 认领资料。更新时，省略字段会保留旧值，只有传 null 才会清除。因此中途只更新 task 没问题，结束时却要把 repo、branch、task 全部置为 null，否则旧分支会一直显示为工作中。

作者还给出了 .claude/settings.json 的自动许可名单：list_granted_resources、list_project_resources、read_session_state、read_session_mail 和 set_status，实际配置都带上工具前缀。

post_session_note 被刻意排除。它会向团队广播，作者希望每次发送都由人确认。这是一种权限取舍，并非接入所必需的唯一配置。

团队收到的是消息，任务不会因此自动启动

原文用 shop-api 的订单舍入修复串起整个流程：先找到 Shop launch 项目和 Release desk 会话，读取状态，再用 read_session_mail 获取最近邮件，示例中的 limit 为 10。

模拟邮件要求：如果修复进入 2.4，需要提供 PR 编号，并说明 API 响应是否变化。随后示例展示了修改 src/orders/total.ts、增加 3 个测试、创建 PR 482，再报告逐行舍入后求和，响应结构不变，但多行订单的总额可能相差 0.01。

这些数字是演示内容。作者明确说，写作机器上没有 Claude Code；工具名和参数名来自在线服务器，仓库、会话、代理、PR 编号及回复都是虚构示例。它说明了预期交互，无法证明实际执行的稳定性。

负责人在 Team mail 中看到笔记，Claude Code 名称旁标有「outside assistant」，接收方显示「→ broadcast」。页面打开时，列表每 5 秒刷新。

笔记送达，不等于代理已经开始处理。

post_session_note 不会自动触发 run，代理在下次运行时才读取消息。否则 Contributor 只需发消息就能间接启动任务，角色限制也就失去作用。

另一个区别是，状态不会出现在 Team mail。它主要供同项目内有席位的代理查看；要核实工具调用，可到 Connected 的 Recent activity 看最近 10 条记录，其中包含工具名、判定和时间。

我的判断

我认可这套设计把「当前状态」「节点消息」「启动任务」分开。相比让助手不断发送自由格式进度，它至少明确了信息用途，也能减少团队判断任务是否结束的成本。

但它有两个前提：团队已经使用 osFoundry，而且有人或代理会持续读取会话。对于主要围绕 GitHub PR 协作的团队，PR 描述、评论和 CI 状态可能已经足够。原文没有提供沟通耗时、漏报率或其他方案的对照数据，不能据此判断引入新会话一定更高效。

数据边界也应按原文的范围理解。邮箱只返回发给该连接及它自己发送的笔记，不包含内部代理分析；状态只在共同项目内可见，并且属于自行上报，osFoundry 不会与 git 核对。

作者称，除写入笔记和状态的内容外，仓库、diff、测试结果仍留在本地。这也提醒使用者：如果主动把敏感代码写进笔记，它就已经成为发送内容的一部分。至于异常中断后如何清理状态、规则能否稳定执行，原文没有交代。

能拿来做什么

• 如果团队已经用 osFoundry 跟踪开发任务，可以先给 Claude Code 配置 Contributor，并在 CLAUDE.md 中明确开工读邮件、PR 就绪时汇报、收工清理状态这几个节点。
• 在前端或 Node 修复任务中，PR 汇报可以交代行为变化、API 响应结构是否改变以及测试覆盖内容，比单独发送一个 PR 编号更便于团队判断影响。
• 可以沿用作者的许可取舍，让读取和状态更新自动执行，向团队广播的 post_session_note 保留逐次确认，并在重试时复用 idempotency_key。
• 排查同步问题时，分别检查 Team mail、Recent activity 和代理运行时机，先确认消息是否发出，再确认接收方是否运行过。