{"version":"2.1.268","anchor":"auto-mode-availability-tracked-as-ongoing-telemetry-not-jus","canonical_anchor":"auto-mode-availability-tracked-as-ongoing-telemetry-not-jus","heading":"Auto mode availability is now tracked as ongoing telemetry","tier":"internal","area":"Auto Mode","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.268\/e\/auto-mode-availability-tracked-as-ongoing-telemetry-not-jus","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.268","markdown":"### Auto mode availability is now tracked as ongoing telemetry\n\nClaude Code now logs auto mode's availability at startup and reports if it changes during a session\n\n**What**\n\n- A new diagnostic snapshot function builds a combined object describing Claude's \"auto mode\" state: whether it's available, why it isn't if not, whether it's disabled by settings or policy (and which), whether it's disabled by trusted policy, its enabled state and source, whether its circuit breaker has tripped, the default permission mode, and whether it fell back.\n\n- Startup (init) telemetry can now include this snapshot (fields like `autoModeAvailable`, `autoModeCircuitBroken`, etc.), gated by a new `logAutoModeAvailability` flag, and a change tracker is registered so a `tengu_auto_mode_availability_changed` event fires later if auto mode's availability flips during the session.\n\n- The context-metrics call at startup is now wrapped so a failure is caught and logged (\"context metrics failed\") instead of throwing synchronously.\n\n**Why** This gives visibility into whether and why auto mode is available, both at startup and if its availability changes mid-session, and makes startup telemetry collection more resilient to unrelated failures.\n\n- Area: Auto Mode\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 3\/5"}