MCP 登录后选成旧协议

MCP 服务支持 2026-07-28，Python 客户端使用 Client(mode="auto")，第一次浏览器登录后却选中了 2025-11-25；令牌缓存后再次连接，又能选对协议。先核对 SDK 版本，以及首次 OAuth 是否超过了 discovery 的 10 秒等待预算。

这个问题有 mcp==2.1.1 的实际反馈，2.2.0 的对应路径仍会把交互式授权时间算进请求超时。已核对的正式版 2.3.0 修复了原有 OAuthClientProvider 的人机等待计时。

冷登录与缓存令牌为什么不同

auto 模式先发 server/discover 探测现代协议。请求收到 401 后开始 OAuth，客户端等待用户打开浏览器、确认授权，再用取得的凭证重试请求。

旧实现中，等待用户的时间也消耗 discovery 的 10 秒预算。计时先到期，auto 路径就可能退回旧的 initialize。后面授权即使完成、服务端也能返回现代 discovery 结果，客户端却已经选择了旧协议。

因此，要把首次连接的授权过程与缓存令牌后的连接分开观察。只在第二次连接检查协议版本，可能完全看不到问题。日志应记录阶段、状态和协商结果，不能把访问令牌、授权码或完整回调 URL 写出来。

如果浏览器根本没有得到正确授权页，或返回的是资源身份不匹配，应先检查相应授权配置；这篇讨论的是交互式登录占用了探测预算，不负责解释所有 OAuth 错误。

修复没有把 10 秒改成 300 秒

2.3.0 在 OAuthClientProvider 等待 redirect_handler 和 callback_handler 时暂停当前请求时钟，等待结束后继续使用剩余预算。服务端正常回应的等待仍受限制，原来的 discovery 10 秒也没有被取消。

旧部署可选择包含这个修复、与应用接口兼容的客户端版本。不要直接给 Client 添加 discover_timeout_seconds=300.0：这个名字曾是问题中的提议，不是已核对的正式修复入口。

同样，不应导入 SDK 的私有请求时钟当作稳定配置接口，也不应为了首次登录把所有 HTTP 超时都关掉。强制选择某个协议版本会改变协商行为，只有双方确实支持该版本、并符合应用约定时才能另行考虑。

自定义认证与登录取消仍要单独处理

这项修复覆盖的是 SDK 的 OAuthClientProvider。如果应用自己实现了 httpx2.Auth，在认证流程中等待用户，不能假定相同暂停机制自动生效；应检查实际认证实现与请求预算的关系。

暂停人机等待也意味着，请求超时不再负责结束一个始终没人完成的登录。应用要在 callback_handler 中设置合适的等待边界，或允许调用方取消；退出时按原生命周期清理回调监听器与连接。

这里也不能用自动重试业务工具调用弥补握手问题。授权和协议探测的重试，与已经可能产生副作用的工具 POST，是不同阶段。

验收首次登录，而非只看连接成功

在获准的测试环境中，使用实际 OAuthClientProvider 走一次未缓存凭证的登录，让用户等待超过原来的 10 秒，再确认授权完成后协商结果仍是双方支持的现代协议。随后检查缓存令牌路径，确认没有回归。

还应检查始终不回应的服务端仍会按探测预算处理，以及用户取消、回调等待到期能正常结束连接。看到登录页、收到令牌或工具能调用，都不能单独证明协议协商正确，最终选择的 protocol_version 也需要核对。