Bug: Auto Mode drops out of Shift+Tab cycle after sending a message while active

Summary

After enabling Auto Mode via Shift+Tab and then cycling past it (to disable), Auto Mode silently drops out of the Shift+Tab cycle. Subsequent Shift+Tab presses only cycle through default → acceptEdits → plan, with no way to re-enter Auto Mode via the keybinding.

Environment

• Claude Code version: 2.1.112
• OS: Linux (WSL2 on Windows) — Linux 6.6.87.2-microsoft-standard-WSL2
• Model: Opus 4.7 (1M context)
• Plan: Max

Reproduction

1. Fresh Claude Code session — Shift+Tab cycles through 4 modes: default → acceptEdits → plan → Auto Mode.
2. Press Shift+Tab to land on Auto Mode. Verified active.
3. Send at least one user message while Auto Mode is active (this step is required to trigger the bug).
4. Press Shift+Tab to cycle out of Auto Mode (back to default).
5. Now press Shift+Tab repeatedly — the cycle is default → acceptEdits → plan → default. Auto Mode is gone from the rotation.

Negative test (confirms the trigger)

If you skip step 3 — toggle Auto Mode on and off via Shift+Tab without sending any message while it's active — the bug does not reproduce. Auto Mode stays in the cycle across multiple toggles. This strongly suggests the bug is tied to state that gets set when a message is sent under Auto Mode.

Expected Behavior

Shift+Tab should continue to include Auto Mode in the cycle after toggling it off, consistent with how acceptEdits and plan remain in the cycle after being toggled off.

Actual Behavior

Auto Mode is silently removed from the Shift+Tab cycle after the first disable. No way to re-enable via the keybinding in the same session.

Additional Context

• Reproducible in a fresh session — not a one-off. Launch Claude Code, land on Auto Mode, cycle past it, and it drops out of the rotation.
• Other mode toggles (acceptEdits, plan) stay in the cycle after being disabled — only Auto Mode exhibits this behavior.
• Auto Mode has no discoverable CLI flag / slash command surface that I'm aware of — Shift+Tab appears to be the primary affordance, so losing it mid-session effectively locks the user out of Auto Mode until the next session.

Impact

Users who briefly toggle Auto Mode to test or compare behavior can't return to it without restarting the session. Given Auto Mode's value for long-running tasks, this is a meaningful usability regression whenever it triggers.

Related

• #49375 — possibly the same bug. That report notes Auto Mode becomes unreachable via Shift+Tab after initial use, which matches this symptom. Filing separately because the trigger identified here (sending a user message while Auto Mode is active) isn't confirmed in that issue, so the root cause may differ. Maintainers should feel free to consolidate if triage confirms they're the same.