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
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

  1. Open 2 or more Claude Code sessions in the same VSCode window (default claudeCode.preferredLocation: panel).
  2. Observe the session tabs in the panel.
  3. 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: true also avoids it, since it removes the webview panel entirely.

Environment

  • Extension: anthropic.claude-code 2.1.195
  • VSCode on Linux (a vscode-server 2.1.183 host is also present)
  • OS: Linux (zen kernel 7.0.13-zen1)

View original on GitHub ↗

5 Comments

Lau-bit · 2 months ago

I also have this issue and use 3-5 Claude Code extension tab instances in VsCode editor windows at once.

Lau-bit · 2 months ago

Bug report: focus loop between multiple visible Claude panels on window re-activation

Target: anthropic.claude-code VS Code extension
File 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-code 2.1.195 (also seen on 2.1.190–2.1.193)
  • VS Code 1.126.0
  • Windows 11 Pro (26200)
  • 3–5 Claude Code panels open as editor tabs, two or more visible at once in split editor groups

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

  1. Open 2+ Claude Code sessions as editor tabs and arrange them so two or more are visible at the same time (side-by-side editor groups).
  2. Click into one Claude panel's input so a Claude webview has keyboard focus.
  3. Alt-Tab (or click) to another desktop application, so VS Code loses OS focus.
  4. Click/Alt-Tab back into a Claude panel.

→ 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:

  • On WM_ACTIVATE (window regains focus), VS Code restores focus to the last-focused webview. That panel's focus handler runs and focuses its input.
  • The other visible Claude webviews also react to the document/window regaining focus and each re-focus their own input.
  • Because the handler fires on every visible panel rather than only the active one, the focus events bounce between panels and re-trigger each other — an infinite loop rather than a single settle.

Two observations that pin it down:

  • It does not happen on cold startup, even with 5 panels restored at once — startup makes only one panel active, so there's no simultaneous multi-panel re-focus.
  • It is fully avoided if a non-webview element (e.g. the Explorer or a normal editor) holds focus at the moment the window regains focus. That strongly implies the trigger is "a Claude webview is the focused element on window-activate, while ≥2 are visible."

Suggested fix

Guard the focus-on-activate / focus-on-visible handler so that:

  • Only the active panel reclaims keyboard focus on a window-activate event — non-active visible panels should not self-focus; and/or
  • add a re-entrancy guard / short debounce so a focus triggered programmatically (not by a user gesture) does not immediately re-trigger a sibling panel's focus handler.

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.

Lau-bit · 2 months ago

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:

  1. Two Claude panels are visible. Panel A proposes a file edit.
  2. The diff/approve editor opens into the active group, which is panel B's

group — so the diff lands as a tab on top of panel B's webview.

  1. Pressing Accept (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 is claudeCode.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.

You-lius · 2 months ago
I also have this issue and use 3-5 Claude Code windows at once.

VSCode is not Claude code. vscode has an extension for claude.

Lau-bit · 2 months ago

Right, I meant Claude Code extension instance tabs open in VsCode for Windows, not other versions of Claude Code.

Showing cached comments. Read the full discussion on GitHub ↗