MCP 登录可以走 Cursor 托管的回调页
IDE 3.24 写明，拒绝指向本机的重定向地址的 MCP OAuth 应用，可以通过 Cursor 托管的回调页完成登录。另一扇窗口占着本机回调端口时登录仍能完成，过大的浏览器请求头也不再导致失败。回调页的主机名原文没有写出。
cursor mcp 登录回调在 IDE 3.24 里多了一条不依赖本机地址的路。发行说明写：如果 MCP 服务器的 OAuth 应用拒绝指向你自己电脑的重定向 URL，现在可以通过 Cursor 托管的回调页登录。另一扇 Cursor 窗口或其他应用占着本机回调端口时，登录也能完成。过大的浏览器请求头不再导致这次登录失败。
三条失败被分开写了
第一条是 OAuth 应用不接受 localhost 一类指向本机的重定向。以前登录停在对方拒绝这个地址。3.24 的替代是 Cursor 托管的回调页。说明没有写出这个页面的主机名，也没有写你要在 OAuth 应用里预登记哪一条 URL。登记仍然在那个 OAuth 应用的后台，不在 Cursor 的 MCP 列表里自动完成。
第二条是本机端口被占用。另一扇窗口已经听着回调端口时，登录不再因此失败。说明没有写端口号。不要为了“腾端口”去关掉所有 Cursor 窗口，这条的意思是占用不再等于失败。
第三条是浏览器请求头太大。说明只说不再因此失败，没有写头的字节上限，也没有写是哪一个头。
这三条都在 “More reliable MCP server sign-in” 下面。同一版后文还有别的登录修复，例如被 Google Workspace 或 Microsoft Entra 管理策略挡住时会说明原因，而不是反复弹登录。那是管理策略，不是回调地址。过期的 Slack、Supabase、Make、HubSpot 登录会要求重新连接。微软的 MCP 会显示账号选择器。这些都不是托管回调页这一句。
和命令行里的 client id 占位不是同一处
CLI v2026.10.08 处理的是未展开的环境变量被当成 client id，见 CLI 不再发送占位 client id。IDE 3.24 这一节不改 client id 的字符串，改的是重定向落在哪、端口被占时还能否完成、请求头过大时还是否失败。
写作日没有走通一次托管回调。OAuth 应用仍只登记了本机地址、又拒绝本机地址时，只升级 Cursor 不会在对方后台替你加上托管回调。对方若要求预登记，那一步仍在对方的控制台。