[BUG] Permission mode resets to different mode when switching editor tabs via Ctrl+Tab / Ctrl+Shift+Tab

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

The Claude Code permission mode (e.g. "Bypass Permissions", "Plan Mode", "Auto Accept Edits") silently changes to a different mode when switching between editor tabs using Ctrl+Tab (next tab) or Ctrl+Shift+Tab (previous tab). No user action is taken to change the mode — it happens as a side effect of normal tab navigation.

This is especially disruptive because:

• It breaks workflow continuity — you set a mode intentionally, then it changes without notice, causing Claude to behave differently than expected (e.g., suddenly asking for permission on every action, or entering plan mode mid-task).
• It's unpredictable — the mode it switches to varies. Sometimes it goes from "Bypass" to "Plan", sometimes to "Auto Accept Edits", sometimes to "Ask Before Do". There is no consistent pattern.
• It's silent — there is no visual notification that the mode changed, so users often don't realize it until Claude's behavior suddenly feels wrong.

What Should Happen?

Permission mode should never change unless the user explicitly changes it (via Shift+Tab cycle or UI). Editor tab switching is a navigation action and should have zero side effects on Claude Code's internal state.

Steps to Reproduce

1. Open Claude Code in the VSCode/Cursor extension (sidebar panel)
2. Set permission mode to "Bypass Permissions" (or any non-default mode)
3. Have multiple editor tabs open
4. Use Ctrl+Tab / Ctrl+Shift+Tab to switch between editor tabs several times
5. Observe that the Claude Code permission mode has changed to a different mode

Key detail: Ctrl+Shift+Tab is a single key chord — it is NOT Shift+Tab (which is the intentional mode cycle shortcut). The OS and editor treat Ctrl+Shift+Tab as a completely different keystroke from Shift+Tab. Despite this, switching tabs appears to trigger the same effect as if Shift+Tab (mode cycle) was pressed.

Root Cause Hypothesis

This is likely not a keybinding conflict. I verified this by:

• Inspecting all Shift+Tab bindings in Cursor's keyboard shortcuts panel — composer.openModeMenu is the only mode-related binding, and its when clause requires composerFocused
• Removing the composer.openModeMenu binding entirely (adding -composer.openModeMenu to keybindings.json) — the problem persisted

This suggests the mode reset is triggered by an internal state/focus change event within the extension when tabs are switched, not by a keybinding being intercepted.

Related Issues

• #24084 — Identical reproduction steps (Ctrl+Tab switching causes erratic mode changes) — closed as stale/locked, but the bug was never resolved
• #35822 — Permission mode resets mid-conversation on VSCode (Linux) — reporter noted correlation with IDE file context attachment
• #27380 — Permission bypass mode resets when switching between concurrent sessions

All three issues describe the same fundamental problem: permission mode state is not stable across focus/tab changes. This issue consolidates the reports with a clearer reproduction path and cross-platform confirmation.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version — the problem has become significantly worse in recent extension updates

Claude Code Version

Latest (VSCode/Cursor extension)

Platform

Anthropic API (Max subscription)

Operating System

Windows 11

Terminal/Shell

Cursor (VSCode fork) — integrated Claude Code extension panel

Additional Context

• Editor: Cursor (VSCode fork), but #24084 reports the same on native VSCode + macOS, and #35822 on VSCode + Linux — this is cross-platform
• Ctrl+Tab / Ctrl+Shift+Tab are rebound to workbench.action.nextEditor / workbench.action.previousEditor (standard sequential tab switching, not the default MRU picker)
• The problem occurs even without the Cursor-specific composer.openModeMenu binding