{"version":"2.1.281","anchor":"remote-managed-settings-fetch-telemetry-gains-auth-diagnosti","canonical_anchor":"remote-managed-settings-fetch-telemetry-gains-auth-diagnosti","heading":"Remote managed settings fetch telemetry gains auth diagnostics","tier":"internal","area":"Telemetry","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.281\/e\/remote-managed-settings-fetch-telemetry-gains-auth-diagnosti","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.281","markdown":"### Remote managed settings fetch telemetry gains auth diagnostics\n\nThe remote managed-settings fetch event now also reports how sign-in went, including token source, refresh results and server errors\n\n**What**\n\nThe `tengu_remote_settings_fetch` telemetry event now also records details about authentication, meaning how Claude Code proved who you are when it fetched settings. The new fields are:\n\n- `auth_type`, `token_source` and `credential_origin` (either `stored_login` or `injected_token`)\n\n- the outcomes of any token refresh\n\n- `retried_after_401`, which shows whether the request was retried after the server said it was not authorized\n\n- the server's error type and code, and `server_auth_denial`\n\n- `credential_state`, `errno` and `ms_since_startup`\n\n- `api_key_prefix`, sent only when you are signed in with an API key\n\n**Why**\n\nWhen remote managed settings fail to arrive, these fields make it possible to tell whether sign-in was the cause and where it went wrong. If you use an API key, note that the start of it is included in this event.\n\n- Area: Telemetry\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 1\/5"}