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

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

When the Claude Code panel opens in a new editor column, the extension programmatically locks that editor group by executing workbench.action.lockEditorGroup. Because the lock is applied imperatively, it bypasses the user's workbench.editor.autoLockGroups setting entirely — setting "mainThreadWebview-claudeVSCodePanel": false there has no effect. The extension exposes no setting of its own to opt out (verified against contributes.configuration of v2.1.217).

Consequences for users who don't want the lock:

• Files opened afterwards spawn new splits instead of opening as tabs in the existing group (VS Code routes new editors away from locked groups).
• The lock must be manually removed via "View: Unlock Editor Group" after every panel open / window reload.
• Locked groups are sometimes left behind after the panel closes (see #20324, #7752).

Verified in the shipped extension.js of v2.1.216 / v2.1.217 (minified; Pe = vscode, u = panel manager):

Pe.commands.registerCommand("claude-vscode.editor.open", async (g, x, w) => {
  if (w !== Pe.ViewColumn.Active) r.setPreferredLocation("panel");
  let { startedInNewColumn: E } = u.createPanel(g, x, w);
  if (E) await Pe.commands.executeCommand("workbench.action.lockEditorGroup");
})

The lock is unconditional whenever startedInNewColumn is true.

Proposed Solution

Add a boolean setting, e.g. claudeCode.lockEditorGroupOnOpen (default true to preserve current behavior), to contributes.configuration, and gate the lock call on it:

const shouldLock = vscode.workspace
  .getConfiguration("claudeCode")
  .get<boolean>("lockEditorGroupOnOpen", true);
if (startedInNewColumn && shouldLock) {
  await vscode.commands.executeCommand("workbench.action.lockEditorGroup");
}

If the same pattern exists on other paths (e.g. the claudePlanPreview panel or the webview serializer/restore path), those should respect the setting too.

Alternative (or complementary): let VS Code's built-in workbench.editor.autoLockGroups mechanism drive the locking via the mainThreadWebview-claudeVSCodePanel view type instead of executing the command imperatively — then the existing user-facing VS Code setting would work as users expect.

Alternative Solutions

• workbench.editor.autoLockGroups overrides for mainThreadWebview-claudeVSCodePanel and mainThreadWebview-claudePlanPreview set to false — no effect, since the lock is programmatic.
• Manually running "View: Unlock Editor Group" — must be repeated after every panel open / window reload.
• Binary-patching the installed extension (if(E) -> if(E&&!1)) — works, but must be re-applied after every extension update.

Priority

Medium - Would be very helpful

Feature Category

Configuration and settings

Use Case Example

1. Open a project in VS Code/Cursor with the Claude Code panel in a side column.
2. Open two files from the explorer.
3. Today: the second file opens in a new split because the Claude group locked the layout; I unlock the group by hand, and again after the next reload.
4. With "claudeCode.lockEditorGroupOnOpen": false, files open as normal tabs and the layout stays under my control.

Additional Context

Related issues:

• #18337 — same underlying behavior reported as a bug, closed as not planned (hence this explicit opt-out feature request)
• #20324 / #7752 — locked panels left behind in VS Code
• #79287 — editor focus/group behavior change after 2.1.215

Environment: anthropic.claude-code v2.1.216 / v2.1.217, VS Code and Cursor, macOS (Darwin 25.5.0).