让 Codex CLI 记住上次看到哪：用 osFoundry 游标实现增量变更追踪

这篇教程讲如何把 Codex CLI 通过 MCP 接入 osFoundry，用三个只读工具加一个游标文件，让它只拉取上次检查之后的新变更，而不是每次重读全部笔记和频道。作者给出了完整配置步骤、AGENTS.md 模板和一次模拟运行示例，并说明了权限边界和几个容易踩的坑。

整体思路：三个工具加一个游标文件

• Codex 先调 list_granted_resources 看自己被授权了哪些资源，再用 list_project_resources 列出项目内容
• poll_resource_events 只拉取某个资源在 after_sequence 之后的事件，每次一个资源，没有全项目游标
• 每个资源的最后序列号存在仓库里的 .osfoundry/cursors.json，下次会话从上次的位置继续
• 所有调用都会出现在 osFoundry 连接的 Recent activity 里，服务端轮询只读不写

配置四步走

• 在 osFoundry 的 Connected 页添加 Other MCP client，然后在 Codex 侧执行 codex mcp add osfoundry --url … 和 codex mcp login osfoundry
• 权限由项目所有者决定：把连接加入项目即授予该项目笔记、知识库、record channels、GitNest 仓库等及项目讨论频道；其他 Message channel 需单独 Invite
• 保留 list_granted_resources、list_project_resources、poll_resource_events 及 read_note_tab、read_channel_messages 等读取工具；在服务端取消勾选的工具会直接失效
• 在 ~/.codex/config.toml 里用 enabled_tools 限定这六个只读工具，Codex 执行时无需逐次确认

用 AGENTS.md 管好游标

• 游标格式为 {"<resource_type>:<resource_id>": <last sequence>}，先 list_granted_resources，清掉已不再返回的资源的游标
• 每个被监控资源用文件里的 after_sequence 调 poll_resource_events，limit 设 100，页满就从最后一序列号继续翻
• 新资源没有游标时，先用 after_sequence 0 拉一次拿到当前序列号
• 关键顺序：先汇报变更，再把新序列号写回文件——这样会话中途挂掉也不会丢事件

一次运行的成本对比

• 示例会话共 4 次 poll 加 2 次读取：两个资源有更新（笔记改了发布时间、频道新增 5 条消息），两个无变化
• 没有游标的话，同样的回答需要整篇重读三份笔记和整个频道再和记忆比对，而 Codex 每次会话记忆为零
• 作者注明该会话是模拟的，但工具名和参数与线上服务器一致，前缀为 mcp__osfoundry__

边界与限制

• Codex 只能看到 list_granted_resources 列出的内容，不能按名字主动请求某个项目；未受邀的 Message channel 始终不可见
• 这是轮询不是订阅，osFoundry 不会主动唤醒 Codex，但配合游标让每次检查成本很低
• 所有者移除项目后相关 poll 会失效，下次 list_granted_resources 也不再返回，此时应丢弃对应游标而不是重试
• Graph 会话是特例：只有所有者在桌面端开启 Share desktop Graph sessions 且应用在线时才可访问，本地数据对云端客户端不可用