{"version":"2.1.314","anchor":"oauth-401-recovery-distinguishes-an-sdk-host-fd-token","canonical_anchor":"oauth-401-recovery-distinguishes-an-sdk-host-fd-token","heading":"Skipped sign-in recovery for SDK-supplied tokens is now reported separately","tier":"internal","area":"Auth","scope":"individual","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.314\/e\/oauth-401-recovery-distinguishes-an-sdk-host-fd-token","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.314","markdown":"### Skipped sign-in recovery for SDK-supplied tokens is now reported separately\n\nWhen Claude Code skips sign-in recovery because the program hosting it supplied the token, it now reports that as its own reason\n\n**What**\n\nWhen the service rejects Claude Code's sign-in, Claude Code can try to recover by getting a fresh login token, and it records why when it does not. There is now a separate reason, `oauth_401_skipped_sdk_host_fd_token`, for when recovery is skipped because the token came from the program hosting Claude Code through the SDK. Before, the reasons covered a token from your environment and the cases with no refresh token.\n\n**Why**\n\nThis splits one kind of failure out in diagnostic reports, so a sign-in problem in an SDK setup is easier to tell apart from the others.\n\n- Area: Auth\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 1\/5\n- Scope: individual\n- Heads-up: no"}