{"version":"2.1.225","anchor":"oauth-401-recovery-no-longer-silently-replaces-a-user-suppli","canonical_anchor":"oauth-401-recovery-no-longer-silently-replaces-a-user-suppli","heading":"OAuth 401 recovery no longer silently replaces a user-supplied token","tier":"use","area":"Auth","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.225\/e\/oauth-401-recovery-no-longer-silently-replaces-a-user-suppli","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.225","markdown":"### OAuth 401 recovery no longer silently replaces a user-supplied token\n\nYour explicitly set OAuth token is no longer silently swapped for a stored credential after a 401.\n\n**What**\n\nA 401 no longer causes Claude Code to swap in a credential from disk when you explicitly supplied `CLAUDE_CODE_OAUTH_TOKEN`.\n\n**Details**\n\n- When the token came from the user's environment, and this is not a remote child session or a unix-socket setup, an explicit error is logged and the supplied token is kept\n- The disk-recovery path now additionally requires the stored credential to be unexpired\n- The whole env\/disk recovery block is skipped when credentials are host-managed via `CLAUDE_CODE_PROVIDER_MANAGED_BY_HOST`\n- The recovery failure reason gained a third value for the skipped-user-env-token case, alongside background-worker and interactive no-refresh-token\n\n**Evidence**\n\n`OAuth 401: keeping the user-supplied CLAUDE_CODE_OAUTH_TOKEN instead of adopting the stored credential.`, `oauth_401_skipped_user_env_token`\n\n- Area: Auth\n- Names: `CLAUDE_CODE_OAUTH_TOKEN`, `CLAUDE_CODE_PROVIDER_MANAGED_BY_HOST`\n- Tier: Use it now\n- Useful: 4\/5\n- Signal: 0\/5"}