未填的 OAuth 客户号不再发出
Cursor CLI v2026.10.08 修复 MCP 的 OAuth：客户号仍是未替换的 ${VAR} 时，CLI 把它当成没设置，不再把占位符原文发给授权服务器。登录因此不再以一种含糊的客户号错误失败。说明没有写变量已经填好时的行为。
配置里还写着 ${VAR}，授权服务器却收到了这串字面量。Cursor CLI v2026.10.08 把这种情况改掉。cursor cli mcp 占位 client id 的处理是：MCP 服务器的 OAuth 配置里，客户号仍是没有替换的 ${VAR} 时，CLI 把客户号视为未设置，不再把占位符原文送出去。登录不再因为一种含糊的客户号错误而失败。
未设置和「用占位符当客户号」不是同一种请求
修复前，字面量 ${VAR} 会被当成客户号发给授权服务器。服务器不认识这个客户，返回的错误容易让人去查网络或回调地址。v2026.10.08 起不再发送这串字面量。日志没有写新的错误原文，只说不再出现那种含糊的客户号错误。
变量若已经在环境里有值，这句不适用。它只管「仍未解析」的占位符。解析成功后的客户号该不该发送，日志没有改口。密钥、令牌以外的字段里若也有 ${VAR}，这句的主语只是 client ID。
另一个 Cursor 应用已经占用登录回调端口时，登录失败是同一版里另一条修复：不再因为端口被占而失败。那条不涉及客户号文本。两条都可能导致「MCP 登不上去」，看报错里有没有把 ${ 当成客户号。
把占位符换成真客户号，这句没有代劳
视为未设置之后，登录仍需要一个真实客户号或该服务器支持的其他登录方式。日志没有写 CLI 会自动注册动态客户。占位符消失只是不再把错误的字符串发出去。配置里继续留着 ${VAR}、环境里又没有这个变量，登录不会突然成功。
写作日没有配一条带占位符的 MCP。升级后若仍失败，看发出的客户号是不是已经不再是 ${VAR}。是别的拒绝原因时，这篇对不上。