[FEATURE] Setting to disable automatic editor group locking in the VS Code extension

@bcherny this issue was first raised nearly a year ago and the subsequent issues have had many comments and thumbs ups! Fix should only be a few lines! :)

@bcherny How can I spend tokens if im slowed down by a lock.
If I want to click and drag all day I would play OSU.

for those who need some temporary solution: https://github.com/ChubbyDuck/patch-claude-code-lock

please resolve, this is so frustrating!

Still present in 2.1.263, and the 2.1.26x line made it structurally unavoidable.

Environment

| | |
|---|---|
| Extension | anthropic.claude-code 2.1.263 (installed on the remote, linux-x64) |
| VS Code | 1.136.1, commit a44adf7f53e00964ab890f9f8758a334f1fc15bc |
| Client OS | Windows 11 x64 |
| Remote | Linux x64 over Remote-SSH |
| claudeCode.preferredLocation | panel |

What happens

Every session opened from the sidebar session list — and every + New session —
lands in a dedicated right-hand editor group that carries the lock icon, regardless
of which editor group has focus. Clicking a file in the center group first to make it
active does not help.

Why focusing the center group cannot work

Per the decompiled createPanel() in #83333, the column is chosen by looking for a
tab group whose tabs are all claudeVSCodePanel:

i = Tt.ViewColumn.Beside;
let a = Tt.window.tabGroups.all.find(/* group whose tabs are all claudeVSCodePanel */);
if (a && a.viewColumn) i = a.viewColumn;
else i = this.findUnusedColumn(), n = true;

My center group holds regular source files, so it can never satisfy the
"all tabs are Claude panels" condition. The lookup therefore always resolves to the
right-hand Claude-only group, and ViewColumn.Active / real focus never enters the
decision. When no such group exists it falls through to findUnusedColumn(), which
spawns yet another column. Neither branch can ever target the center group.

The lock icon itself comes from the unconditional
workbench.action.lockEditorGroup call documented in this issue. As expected,
"workbench.editor.autoLockGroups": { "mainThreadWebview-claudeVSCodePanel": false }
has no effect, since the lock is applied imperatively.

Worth noting that VS Code upstream went the opposite way: workbench.editor.chatSession
was removed from the auto-lock default set in microsoft/vscode#278797, with the
rationale that the experience was inconsistent and that a reserved-group-for-chats
layout "needs to be a new editor concept altogether."

Regression window

This worked on Fri 2026-09-04 — sessions opened in the center group. It broke
after the extension auto-updated to 2.1.263 on 2026-09-07.

2.1.261 shipped this line:

[VSCode] Fixed Cmd/Ctrl+Shift+T reopen and deep-link opens placing the Claude tab outside the Claude editor group when a Claude tab has focus

So corralling every Claude tab into one dedicated group is now intended behavior,
which is exactly what makes the absence of an opt-out painful.

Ask

1. claudeCode.lockEditorGroupOnOpen as proposed in this issue's OP.
2. A way to target the active editor group (#86403), i.e. let createPanel()

honour ViewColumn.Active instead of the all-Claude-group lookup.

Current workarounds

• Downgrade to 2.1.251/257 (last known-good) and pin it with

"extensions.autoUpdate": false.

• /resume inside an existing Claude tab — restores in place, bypasses the

group-creation and lock path entirely.

• ChubbyDuck/patch-claude-code-lock patches the minified bundle, but must be

re-applied after every extension update.

Related

• #83333 — findUnusedColumn() creates a stray empty editor group
• #86403 — request for an "open in active editor group" option
• #67419 — session-list clicks ignore preferredLocation
• #92200 — same regression reported 2026-09-04; pins the last good version at 2.1.251, with the break landing in 2.1.258/2.1.259. Closed by its author without a fix, so this issue remains the live thread.

If anyone cares, I fixed this by creating a vscode extension that does what is needed to undo undesired behavior. I told claude what I wanted and it was working 5 mins later.

If you want my extension, here is claude telling how to get it ...

Claude Default Group – https://github.com/mark-hahn/claude-def-grp

What it does:

• When a Claude Code tab opens anywhere but the first editor group, it moves the tab into the first group. The new column Claude created is then empty and closes itself, and the lock goes with it.
• Later Claude tabs open next to the existing one, so Claude never issues another lock.
• It also unlocks the active editor group whenever groups are added, removed or switched, and it sweeps on startup for tabs restored into other groups.
• It runs on the local side of Remote-SSH and WSL windows, so one install covers those too.

Install:

1. Download the .vsix from https://github.com/mark-hahn/claude-def-grp/releases/latest
2. code --install-extension claude-default-group-<version>.vsix (or Extensions view → ... → Install from VSIX...)
3. Reload the window.

Settings live under claudeDefaultGroup (enabled, unlockOnGroupChange, delayMs), and there are two palette commands: Move Claude Tabs to First Group and Unlock All Editor Groups. Activity is logged to the "Claude Default Group" output channel.

It only uses public VS Code commands (moveEditorToFirstGroup, unlockEditorGroup, the focus-group commands) and the tab groups API, so nothing about Claude Code itself is patched. Source is MIT. This is a workaround, not a fix; a claudeCode.lockEditorGroupOnOpen setting as proposed above would still be the right answer.

This appears to have regressed further recently: as of 2.1.259 (published Sept 2, 2026), the editor group lock now happens even without claudeCode.preferredLocation: "panel" set — previously that setting was required to trigger it. Removing the setting entirely no longer avoids the lock on 2.1.259.

Downgrading the extension to 2.1.258 confirmed the lock does not occur there, so this looks like a regression introduced in 2.1.259 on top of the original opt-in behavior reported here.

2.1.246 doesn't appear to have it

Still reproducible in v2.1.263 (VS Code, Windows).

Worth separating two things here, because gating the lock alone would not fix the split:

1. createPanel chooses the column itself. It looks for an editor group made up exclusively of claudeVSCodePanel webviews; if there is none, it falls back to findUnusedColumn() — the first free ViewColumn — which forces a split. Only then does startedInNewColumn trigger workbench.action.lockEditorGroup.

1. The + New session button in the Session manager sidebar always takes that path: the webview sends open_in_editor, which the host maps to claude-vscode.editor.open with no viewColumn argument. So there is no way to click that button and get a plain tab in the group you are working in — the split is unconditional, and no setting reaches it (claudeCode.preferredLocation only picks sidebar vs. panel).

For anyone who keeps chats and files in a single tab strip, every new session tears the editor in two.

Could the fallback be ViewColumn.Active when no Claude-only group exists — either by default, or behind the same setting proposed here?

For reference, #36461 asked for essentially this and was closed as not planned after going stale.

Confirming this still reproduces on VS Code extension v2.1.267.

Also confirmed that claudeCode.preferredLocation: "sidebar" does not work around it — the "+ New session" button routes through the new_conversation_tab request → claude-vscode.editor.open command, which is called without the flag that would preserve the user's preferred location, so it forcibly calls setPreferredLocation("panel") and locks the resulting group whenever startedInNewColumn is true. So the existing setting is not a usable workaround for the "+ New session" flow specifically (only for openLast).

A claudeCode.lockEditorGroupOnOpen (or similar) opt-out as proposed here would fix this.

Still reproduces on 2.1.266 (macOS 26.6.1, VS Code 1.136.2). The imperative lock is unchanged from the OP:

registerCommand("claude-vscode.editor.open", async (O, M, x, w, E) => {
  if (!E) J.setPreferredLocation("panel");
  let { startedInNewColumn: j } = G.createPanel(O, M, x, w, E);
  if (j) await g$.commands.executeCommand("workbench.action.lockEditorGroup");
})

There is a shipped workaround nobody in this thread has mentioned, and it needs no bundle patch, no downgrade and no third-party extension: the sibling command claude-vscode.primaryEditor.open, exposed in the palette as "Claude Code: Open in Primary Editor". From the same 2.1.266 bundle:

registerCommand("claude-vscode.primaryEditor.open", async (O, M) => {
  G.createPanel(O, M, _4$(), void 0, !0)
})

function qp$($)  { return $.tabs.length > 0 && $.tabs.every((Q) =>
                     Q.input instanceof vscode.TabInputWebview &&
                     Q.input.viewType.includes("claudeVSCodePanel")) }
function Np$()   { let { activeTabGroup: $, all: Q } = vscode.window.tabGroups;
                   return qp$($) ? $ : Q.find(qp$) }
function _4$()   { return Np$()?.viewColumn ?? vscode.ViewColumn.Active }

Three consequences:

1. The column argument is always defined, so createPanel takes its J !== undefined branch. startedInNewColumn stays false and no column is spawned, which also avoids the stray empty group in #83333.
2. The command never calls lockEditorGroup on any path, so the lock cannot fire even if the column heuristic changes later.
3. It passes true for the fifth parameter that editor.open tests in if (!E) setPreferredLocation("panel"), so it does not clobber claudeCode.preferredLocation the way the "+ New session" flow does.

The gating context key claude-vscode.primaryEditorEnabled is set true unconditionally during activation, so the command is always available.

Rebinding the extension's own key makes it the default path:

{ "key": "cmd+shift+escape", "command": "claude-vscode.primaryEditor.open" },
{ "key": "cmd+shift+escape", "command": "-claude-vscode.editor.open" }

Limits, so nobody over-reads this:

• When a Claude-only group already exists, Np$() returns that group and the tab lands there. ViewColumn.Active applies only when no such group exists. Either way there is no new column and no lock.
• It does not help the webview-driven paths reported above, such as the sidebar + New session button, which reaches editor.open directly.
• The editor title-bar Claude icon runs editor.openLast, which forwards to editor.open, so that button stays on the locking path. Menu contributions cannot be rebound by users.

So this is a stopgap for user-initiated opens, not a fix. The claudeCode.lockEditorGroupOnOpen opt-out proposed in the OP, plus a ViewColumn.Active fallback in createPanel, is still the right answer. Given that primaryEditor.open already implements exactly the lock-free, active-column behavior being asked for, routing editor.open through the same helper behind the setting looks like a small change.

same problem, broken update, can't use

Please fix and don't force those of us with vision disability to work in whatever way works for you. Just give us the choice.

I need to have my font large to be able to see anything and with this split none of the panels are large enough for me to read anything. It's not a big ask, just go back to allowing us the choice of how we want to work.

I would love if this were fixed 🙂

Please add this feature 🙏