oh-my-pi v15.10.7 发布 —— 三行 bugfix，四个故事
omp v15.10.7 的三个 PR 加一个伴随修复，就是从这种「不可能复现」的 bug 开始的。
故事一：被中断的 thinking block，签名去哪了？
用 Anthropic 的推理模型（Claude Opus 4、Sonnet 4 等）时，模型在「思考」阶段会产出 thinking block，每个 block 在结束时由 Anthropic 服务器签名——这个签名在 content_block_stop 事件里下发。如果你在模型产出 thinking block 后的「可见文本」阶段按了 Ctrl+C（即 interrupt），transformMessages 会把该 turn 里所有 thinking block 的签名清空，包括那些已经完成推送的。
问题是：一个 thinking block 完成后紧跟的 text/tool_use block 已经开始了，中间的 content_block_stop 事件下发的签名是有效的。强行清空后重新发送时，signature: "" 被 Anthropic 检测到并拒绝——签名是完整性校验的一部分，空字符串意味着篡改。
修法只有一行判断：只清除中断时刻那个「当前未完成」的 mid-stream thinking block 的签名，已完成的所有 block 保留原签名。（#2144）
这个 bug 影响的人群很特定：使用 Anthropic 原生 API 或经由 LLM 网关转发、且频繁中断模型输出的人。也就是 omp 的日常用户——因为你每天都在中断它。
故事二：Opus 4.6+ 的 clear_thinking 被误杀
这次还有一个更隐蔽的问题，编号 #2123。Claude Opus 4.6+ 的「自适应思考」（adaptive thinking）模式会发送一个特殊的 clear_thinking_20251015 内容块，它和 thinking 字段是配对出现的。当你设置了 tool_choice: "tool" 或 tool: "any"（强制工具调用）时，omp 调用 disableThinkingIfToolChoiceForced 方法——它会清掉 params.thinking。
但它忘了配套的 context_management 字段。结果就是一个没有 thinking 却有 clear_thinking_20251015 的畸形请求发到了 Anthropic，返回 400：clear_thinking_20251015 strategy requires thinking to be enabled or adaptive。
修复很干净：现在 context_management 和 thinking 字段一起被移除，不留孤儿。
两个 Anthropic 修复讲的是同一个道理：你改了 A 之后，别忘了 B 和 C 是绑在一起的。在 Anthropic 日益复杂的请求结构中（thinking、tool_choice、context_management、beta headers），这种耦合越来越多。
故事三：omp 启动卡了 30 秒，是谁在拖后腿？
这是 #2100。现象：你执行 omp，等待，命令行空白了 25-30 秒，然后突然正常了。你查日志，发现一个 MCP server 超时了，但其他的都好好的。问题是——为什么一个服务器的超时要拖累整个 UI 的 ready 信号？
MCPManager.connectServers 的实现逻辑是：对每个 pending 状态的服务器执行连接，然后用 Promise.allSettled 等所有连接结束。问题是，allSettled 不区分「这服务器有没有缓存工具」——你的 SQLite MCP server 可能需要外部数据库启动 5 秒，而这 5 秒内 omp 不会通知前端「我准备好了」。
更糟的是，如果你配置了一个不被缓存的 MCP server（比如一个只在启动时才注册工具的 server），Promise.allSettled 会把所有待连接服务器捆在一起：一个卡 30 秒，整个 omp UI 就等你 30 秒。
修法：pending 且无缓存的服务器不再阻塞 ready 信号。它们被留在后台，tools 通过 #onToolsChanged → refreshMCPTools 路径异步上浮，连接失败由后台 catch handler 记录。
如果你配了多个 MCP server，升级后最直接的感觉就是——omp 启动速度不再等于最慢那个 MCP 的连接时间。
故事四：字数不多但值得说的
MCP OAuth fallback 的渲染修复。 v15.10.5/v15.10.6 加入了 OAuth fallback，但 terminal 里显示的授权 URL 被折行、覆盖、无法点击复制。现在展示简短超链，原始 URL 保持在一行内可复制。（#2121）
Antigravity 用量计数器独立显示。 如果你同时用 Google/Gemini 和 Anthropic/OpenAI 的 Antigravity 通道，Google 配额耗尽时，之前会把所有计数器的「空闲百分比」都渲染成 0%。现在各通道独立显示：Google 显示 0% free，Anthropic 那边该多少还是多少。
从 v15.10.4 到 v15.10.7，三个版本在 18 小时内连续发布。v15.10.5 做了大幅重构（provider registry 重组、agent loop 流修复）、v15.10.6 修复了 kitty 终端的粘贴问题、ConPTY 滚动截断、shake 死循环——v15.10.7 是这三联发里最小的一包。但三个 bugfix PR 各自挖出了一个值得讲上几百字的问题，因为它们不是「补一个 null check」那种修复，而是「理解了 Anthropic 的 server 状态机、MCP 连接的生命周期、Antigravity 的配额聚合方式」之后才能动的手术。
升级方式：
# 已有安装
omp update
# 全新安装
curl -fsSL https://omp.sh/install | sh
# 或通过 Bun
bun update -g @oh-my-pi/pi-coding-agent
完整更新日志：GitHub Release
📢 关注我，获取最新开源更新日志和开发者工具动态。
#oh-my-pi #Anthropic #MCP #Antigravity #bugfix #AI编程工具