Resumed sessions silently lose capabilities after upgrades (e.g. Auto permission mode missing from picker while its classifier is active)

Summary

Sessions saved before an upgrade/feature-flag fetch repeatedly lose access to capabilities in the UI when resumed later — most recently the Auto permission mode: a long-running session was demonstrably running Auto Mode (permission denials cited "the Claude Code auto mode classifier"), yet Auto was absent from every mode picker in the VS Code extension, and nothing in-session could surface it. This is one instance of a recurring pattern for me: after extension/CLI updates, old saved sessions — which I absolutely need to keep working with — come back missing modes or behaviors they had, with no indication of why.

Environment

• VS Code extension anthropic.claude-code@2.1.263, CLI 2.1.263 (was 2.1.220 before updating during diagnosis), macOS (Darwin 25.5.0)
• Team/paid plan; GrowthBook cache shows tengu_auto_mode_config = {"enabled": "enabled", ...} and tengu_auto_mode_default_on = false
• No disableAutoMode, no telemetry-blocking env vars, no managed settings

What happened

1. Session started under an earlier version, before feature flags were first fetched → mode-availability UI state stamped without Auto.
2. Session runs for days across upgrades. Auto Mode's Bash classifier is active the whole time (denial messages name it), but the mode indicator shows only Manual / Edit automatically / Plan; the plan-approval dialog likewise offers no Auto path.
3. "Developer: Reload Window", CLI update to match the extension, and reopening the panel did NOT restore the picker for the resumed session.
4. Only a brand-new conversation showed Auto; per the docs' mode-resolution rules, resumed sessions only display it again after re-picking Auto once in a new conversation (workspace sticky default).

The 2.1.263 changelog fix ("sessions started before feature flags were first fetched...") helped new sessions, but resumed pre-flag sessions still present a stale picker, and the actual mode diverges silently from what the UI claims.

Why this matters

• UI/behavior desync: the session enforces one permission mode while displaying another. Users cannot tell what mode they are actually in.
• Saved sessions are load-bearing. Long-lived sessions carry days of context. Every upgrade that quietly strips or hides capabilities from resumed sessions costs real work; this has happened to me multiple times in different forms.

Ask

1. Re-evaluate mode/capability availability at resume time from live feature flags and account state — never from state stamped at session creation.
2. Treat saved sessions as durable artifacts across upgrades: a version bump should migrate session UI state, not orphan it.
3. Surface the actual active permission mode in the UI (if the classifier is running, the indicator should say Auto) — and add regression tests for the resume path across version/flag transitions.

🤖 Filed with Claude Code on the user's behalf