{"version":"2.1.314","anchor":"mcp-oauth-records-which-auth-rejections-401403-a-server-r","canonical_anchor":"mcp-oauth-records-which-auth-rejections-401403-a-server-r","heading":"MCP sign-in now records when a server rejects a token","tier":"internal","area":"MCP","scope":"individual","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.314\/e\/mcp-oauth-records-which-auth-rejections-401403-a-server-r","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.314","markdown":"### MCP sign-in now records when a server rejects a token\n\nMCP sign-in records 401 and 403 rejections with the token that was sent, and Clear authentication now checks a result field\n\n**Unclear.** It is not shown how the recorded rejection is used, so the effect on when you are asked to log in again is unclear.\n\n**What**\n\nMCP servers are outside tools Claude Code connects to, and some need you to sign in. The sign-in handling now keeps track of when a server rejects access.\n\n- When an MCP server answers with a 401 or 403 (access refused), Claude Code now calls `noteAuthRejection` with the status and the authorization header it sent. This is stored per server address in a new `_lastAuthRejection` field.\n\n- The rejection is recorded before the existing check for a request with no authorization header, which still returns early. Before, such requests returned immediately and no rejection was noted.\n\n- The \"Clear authentication\" action now reads a `.cleared` value from the result of clearing stored sign-in data, instead of a plain yes\/no answer. If clearing fails you still see \"Authentication for ... was not cleared\", now with the detail \"sign-in data is still stored\".\n\n**Why**\n\nKnowing which token a server rejected lets Claude Code tell whether a refusal applies to the sign-in it currently holds, which can affect when you are asked to sign in again.\n\n- Area: MCP\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 1\/5\n- Scope: individual\n- Heads-up: no"}