osFoundry 为什么让 Codex CLI 按资源用游标轮询，而不是推送变更？

作者用 Python 脚本实测 osFoundry 的 MCP 服务器，发现推送通道全部关闭，只剩一个只读的 poll_resource_events 工具。文章用数据解释了为什么客户端游标比服务器游标更适合 Codex CLI 的运行方式，并用模拟实验给出了轮询频率的最优策略。

三条推送通道全部走不通

• initialize 声明 capabilities 里只有 tools 且 listChanged: false，工具列表变化也不会通知
• resources/subscribe 直接返回 Method not found，对 MCP URL 发 GET 也只得到 405
• 最终只剩一个只读工具 poll_resource_events：按 resource_type 和 resource_id 从某个事件序号之后拉取变更

为什么 Codex 适合轮询而不是推送

• Codex CLI 不是常驻 daemon，跑完一轮就结束或等你输入，推送需要会话之间有东西在监听，笔记本上往往没有
• 游标模式契合这种工作方式：客户端每个资源存一个整数，想回来时问一句这个序号之后发生了什么
• 未认证请求的限流头显示 2000 次/约 61 秒，真正的瓶颈不是服务器负载，而是每次 poll 都要消耗模型的一个工具调用回合

客户端如何发现能查什么

• list_granted_resources 不接受任何参数，schema 直接拒绝多传字段，语义是服务器告知你有什么
• list_project_resources 必须指定 resource_type，没有一次列出项目全部内容的调用，完整盘点要按九种类型逐个调用，超过 50 条还要用 offset 分页
• graph_session 只能 poll 不能 list，需要所有者先在桌面端分享后通过 list_graph_sessions 获取

游标为什么该归客户端管

• 服务器端的 wait_for_messages 会替你存游标并支持最长 50 秒的 long polling，但 poll_resource_events 两者都没有，连 timeout_s 都被拒绝
• 两个终端共用同一登录时，服务器游标会被互相推进：600 个事件两个终端各只看到约一半；客户端自带 after_sequence 则两边都能看全 600 个
• schema 没有强制 after_sequence，省略时行为未定义，所以务必自己保存序号并每次都带上

轮询频率怎么选：模拟 8 小时 30 个资源

• 固定每 30 秒查全部：每小时 3600 次调用，94.7% 是空的，但中位延迟只有 14.9 秒
• 固定每 5 分钟：每小时仅 360 次，但所有资源都慢，中位延迟 150.9 秒
• 按资源做指数退避（空轮询后间隔翻倍、收到事件即重置、上限 10 分钟）：每小时约 502 次，中位延迟 34.9 秒，接近便宜方案的调用量加快速方案的延迟

清空积压事件的成本

• limit 上限 100，一次导入后可能有几百个事件排队，要反复从上次序号拉到出现不满页为止
• 350 个积压事件用 limit 100 需 4 次调用，limit 50 需 7 次，limit 20 需 18 次
• 空页响应只占约 17 个 token，轮询的主要成本在回合数而非读取量，所以尽量请求 limit 100