safari-mcp 作者三天前提交了一个严重 issue：用户的两个标签页被 AI 代理误导航，滚动位置、页面状态丢失。他自信地分析了根因——位置句柄导致标签归属丢失——并提议用注入
window.__mcpTabMarker 的稳定标识方案。实际打开源代码后，他发现：这个哨兵方案早在 v2.8.3（April 14）就已经实现了。真正的 bug 藏在其下方四行：当标签索引超过窗口标签数时，代码不是丢弃索引（fail closed），而是将索引“钳位”（clamp）到tabCount——即指向窗口最后一个标签，一个从未打开的、属于用户的标签。这个“proactive fix”代码段被日志装饰成“修复”，实质是猜答案。
这条 clamp 分支（Mar 31）比哨兵方案（Apr 14）更早，属于遗留启发式。哨兵方案添加时正确连入了两条 fail closed 分支，但这条“输入校验”样式的 clamp 被遗留了。作者总结：当添加更好机制时，旧启发式不会自动删除。任何将“我不知道”转换成合理值的代码，都是披着修复外衣的 fail open。
最终修复只是删除那几行钳位代码，改为activeTabIndex = null; return null;——就像它上下两条分支一样。错误提示引导用户重新运行safari_new_tab来恢复。代价是那些此前“侥幸”成功的 session 会抛出异常，但作者认为：对于“绝不碰用户标签”的承诺，报错是正确答案，猜不是。
修复只是一行删除。作者把错误的根因分析留在 issue 里当警示，并提醒：如果你把同一个 bug 交给 AI 代理，它可能会执行你提出的早已过时的方案，而真 bug 依然存在。
#开发者 #工具 #safarimcp #MCP #Safari #AI #Bug #Javascript #macOS
@DevToolboxHub