VSCode extension: input box flickers and focus rapidly ping-pongs between multiple open session tabs
Status Closed — not planned
Reported on v2.1.195
Maintainer reply None cached
Workaround ✓ Mentioned in thread ↓
Activity 6 comments · opened Jun 27, 2026 · closed Aug 15, 2026
What happened
When multiple Claude Code sessions are open in the same VSCode window (as tabs in the panel), the input box flickers and keyboard focus rapidly "ping-pongs" between the open sessions on its own. This makes it very hard to type into the input box.
Steps to reproduce
- Open 2 or more Claude Code sessions in the same VSCode window (default
claudeCode.preferredLocation: panel). - Observe the session tabs in the panel.
- Focus automatically alternates back and forth between the sessions, and the input box flickers.
Expected behavior
Focus stays in the session the user is interacting with. No automatic focus switching between open session webviews.
Actual behavior
Focus rapidly alternates between multiple open session tabs, the input box flickers, and typing is disrupted.
Workaround
- Keeping only one session per window (separate VSCode windows for concurrent sessions) avoids it.
claudeCode.useTerminal: truealso avoids it, since it removes the webview panel entirely.
Environment
- Extension:
anthropic.claude-code2.1.195 - VSCode on Linux (a
vscode-server2.1.183 host is also present) - OS: Linux (zen kernel 7.0.13-zen1)
Showing cached comments. Read the full discussion on GitHub ↗
5 Comments
I also have this issue and use 3-5 Claude Code extension tab instances in VsCode editor windows at once.
Bug report: focus loop between multiple visible Claude panels on window re-activation
Target:
anthropic.claude-codeVS Code extensionFile at: https://github.com/anthropics/claude-code/issues
---
Title
Focus loop between multiple visible Claude webview panels when VS Code regains window focus
Environment
anthropic.claude-code2.1.195 (also seen on 2.1.190–2.1.193)Summary
When two or more Claude Code webview panels are visible simultaneously (in separate editor groups) and VS Code loses and then regains OS window focus while a Claude panel held keyboard focus, the panels get stuck in a rapid mutual focus loop — keyboard focus jumps back and forth between the Claude panels and never settles. The user has to click into one panel (sometimes several times) to break it.
Steps to reproduce
→ Focus rapidly oscillates between the visible Claude panels.
Expected
On window re-activation, focus returns to the single previously-active panel and stays there.
Actual
All visible Claude panels appear to reclaim focus on the same window-activate event, and the result is a sustained focus-stealing loop between them until the user manually clicks to pin focus.
Analysis / suspected cause
This has the signature of a mutual re-entrancy loop in the panel's "restore focus on visible/activate" handler:
WM_ACTIVATE(window regains focus), VS Code restores focus to the last-focused webview. That panel's focus handler runs and focuses its input.Two observations that pin it down:
Suggested fix
Guard the focus-on-activate / focus-on-visible handler so that:
Either change should break the loop at the source.
Current workaround (external)
A small companion extension hooks
window.onDidChangeWindowState: on blur, if a Claude webview is active and 2+ are visible, it parks focus on a neutral non-webview element; on regain, the window restores to neutral (no loop), then after a short delay it returns focus to the Claude group. This reliably eliminates the loop but leaves one unavoidable extra focus event on return (the re-entry into the webview), which only an in-extension fix can remove.Follow-up (message 2 of 2) — items found after the original report
*Continuation of the focus-loop bug report. The original report stands on its
own; after sending it I found a second trigger for the same loop and confirmed a
relevant config gap. These are still under active assessment and testing, so
treat them as preliminary updates.*
1. Additional trigger — no window focus change required
The loop can also be triggered entirely inside the window, with no Alt-Tab:
group — so the diff lands as a tab on top of panel B's webview.
claude-vscode.acceptProposedDiff) closes the diff tab,panel B's webview is revealed and re-focuses on becoming active, and that
re-focus competes with panel A → the same loop.
This confirms the root cause is general: any event that re-focuses a Claude
panel while 2+ are visible — window re-activation or a tab closing to reveal
a panel — can ignite it. A fix at the focus-on-activate/visible handler covers
both.
2. No setting controls where the diff editor opens
Checked
claudeCode.*in 2.1.195: there isclaudeCode.preferredLocation(where Claude itself opens) but nothing governing where the diff/approve editor
opens, so users can't keep it from landing on another panel's group.
3. Residual single-event variant (under assessment)
Even with the loop itself broken, we still occasionally see a single stray
focus event after window re-activation — one panel taking focus just once, which
is enough to misdirect typed text to the wrong panel. We are still testing
whether this is a leftover single self-focus on activate vs. an artifact of the
external workaround, and will update.
Status
Under further assessment and testing — will follow up if findings change.
The suggested fix is unchanged: guard the focus-on-activate/visible handler so
that only the active panel reclaims focus (and/or add a re-entrancy guard). That
should cover both triggers and the single-event variant above.
VSCode is not Claude code. vscode has an extension for claude.
Right, I meant Claude Code extension instance tabs open in VsCode for Windows, not other versions of Claude Code.