[BUG] VS Code extension: clicking a file link opens the file into the Claude editor group, which then breaks new-session placement

Status Open
Reported on v2.1.263
Maintainer reply None cached
Activity 0 comments · opened Sep 15, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report
  • [x] I am using the latest version of Claude Code

What's Wrong?

Two behaviors in the VS Code extension interact badly, and the result reads as nondeterministic session placement.

1. Clicking a file link in a reply opens the file into the Claude editor group.

openFile calls vscode.window.showTextDocument(uri) with no TextDocumentShowOptions, so VS Code resolves it to the active editor group. When clicking a file link from a reply, the active group is almost always the Claude group — so the file tab lands there.

2. New session placement requires that group to be pure.

createPanel picks a column via no$(), which only reuses a group where every tab is a claudeVSCodePanel webview:

Yk = group => group.tabs.length > 0 && group.tabs.every(h8$)
h8$ = tab => tab.input instanceof TabInputWebview && tab.input.viewType.includes("claudeVSCodePanel")

So step 1 pollutes the exact condition step 2 depends on. After one file link click, the Claude group contains a text editor, Yk returns false, no$() returns undefined, and the next session falls through to findUnusedColumn() — splitting off a new column.

From a user's point of view there is no visible pattern: sometimes a new session joins the existing group, sometimes it opens its own column. The trigger (having clicked a file link earlier) is not discoverable.

What Should Happen?

Clicking a file link should open the file in a group intended for files, not into the Claude webview group — and new session placement should stay predictable regardless of whether file links were clicked.

The extension already has the logic to distinguish the two kinds of group (h8$ / Yk / no$), but openFile does not use it. Resolving a non-Claude viewColumn and passing it explicitly to showTextDocument would address both symptoms.

Steps to Reproduce

  1. Open a Claude session in an editor group. Keep that group free of file tabs.
  2. Start a second session — it correctly joins the first as a tab in the same group. ✅
  3. In any reply, click a file path link. The file opens into the Claude group, next to the session tabs.
  4. Start a third session — it now splits off into a new editor column instead of joining. ❌
  5. Move the file tab out of that group, then start a fourth session — it joins correctly again. ✅

Step 5 confirms group purity is the deciding factor.

Is this a regression?

I don't know

Claude Code Version

2.1.263 (Claude Code) — VS Code extension 2.1.272 (darwin-arm64)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Cursor

Additional Information

No setting works around this:

  • None of the claudeCode.* keys affect editor placement. preferredLocation only selects sidebar vs panel and is not read by createPanel's column logic.
  • VS Code's workbench.editor.* settings do not change which group an options-less showTextDocument resolves to. openSideBySideDirection only applies once a split is already decided, which is not the case here.

Possibly related, though asking for the opposite placement: #86403.

View original on GitHub ↗