Feature Request: Bidirectional runtime switching between all permission modes

Problem Statement

The current permission mode architecture creates an asymmetric switching problem that forces users into suboptimal default choices.

The Asymmetry

Claude Code currently supports three permission modes:

1. plan - Thoughtful planning before execution
2. auto-accept - Auto-accepts file edits only
3. bypassPermissions - Full automation

However, runtime switching via Shift+Tab only works from certain modes:

• ✅ Can switch FROM bypassPermissions → plan (via Shift+Tab)
• ✅ Can switch FROM auto-accept → plan (via Shift+Tab)
• ❌ Cannot switch FROM plan → bypassPermissions
• ❌ Cannot switch FROM plan → auto-accept

The Dilemma

This creates a forced trade-off for users who prefer planning as their cognitive default:

Option A: Set defaultMode: "plan"

• ✅ Start with planning (desired behavior)
• ❌ Stuck in plan mode for simple tasks
• ❌ Cannot switch to bypass for rapid iteration

Option B: Set defaultMode: "bypassPermissions"

• ✅ Can toggle to plan when needed
• ❌ Must remember to activate plan mode
• ❌ Cognitive overhead of mode management

Root Cause Analysis

The asymmetry stems from the conceptual model where plan mode is treated as an "elevated" state you can enter, but not a peer mode you can exit to other modes. This creates a one-way valve in the state machine.

Proposed Solution

Implement bidirectional mode switching that treats all permission modes as peers:

Implementation Options

Option 1: Extended Shift+Tab Cycling

Shift+Tab cycles: current → plan → auto-accept → bypassPermissions → current

Option 2: Mode-Specific Shortcuts

• Shift+Tab: Toggle to/from plan mode
• Shift+Alt+Tab: Toggle to/from bypassPermissions
• Visual indicator shows current mode

Option 3: Slash Commands (Complements shortcuts)

/mode plan              # Switch to plan mode
/mode bypass            # Switch to bypassPermissions
/mode auto              # Switch to auto-accept
/mode                   # Show current mode

Technical Considerations

The state machine should support:

1. Persistent mode during session - Mode persists until explicitly changed
2. Revertible default - Option to return to settings default
3. Visual feedback - Clear indication of current mode in UI
4. Graceful transitions - Handle mid-operation mode switches appropriately

Use Cases

Scenario 1: Complex Feature Development

1. Start in plan mode (default)
2. Plan the implementation
3. After approval, switch to bypassPermissions for rapid iteration
4. Switch back to plan for next complex task

Scenario 2: Bug Investigation

1. Start in plan mode (default)
2. Plan investigation approach
3. Switch to bypass for exploratory commands
4. Return to plan for fix implementation

Impact

This enhancement would:

• Remove the cognitive overhead of "wrong default" selection
• Enable fluid workflows that match task complexity
• Support users who think in "plan-first" patterns
• Eliminate the need for session restarts

Related Issues

• #3429 - Requests /plan command (partial solution)
• #5039 - Requests mode switching commands (similar goal)
• #2798 - Requests plan as default (symptom of this problem)

Alternative Minimal Implementation

If full bidirectional switching is complex, consider at minimum:

• Add ability to exit plan mode to bypassPermissions
• This single addition would resolve the asymmetry

Closing Thoughts

The current architecture implicitly assumes bypassPermissions as the "base" mode, with plan as a temporary elevation. However, many developers naturally think in a "plan-first" paradigm, especially for complex systems. Supporting bidirectional switching acknowledges both cognitive styles as equally valid.

This isn't just about convenience—it's about supporting diverse problem-solving approaches and reducing the friction between thought and implementation.