[BUG] VS Code extension silently closes and relaunches chat channels ("Closing Claude on channel") with no trigger — occasional config lock race on resume

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

The Claude Code chat panel intermittently closes and relaunches the active chat session's backend process on its own, with no user action and no VS Code-level event to explain it. The extension's own log shows an internal "Closing Claude on channel: <id>" followed by "[uds-messaging] Shutting down", then a fresh process spawn with --resume=<same session id>.

This happened 3 times in ~25 minutes of one session:

• Once right after switching editor tabs (single channel closed).
• Twice with NO preceding trigger at all in the logs — including once mid-response-stream — and affecting TWO independent open chat tabs simultaneously.

No data is lost (the conversation resumes via --resume), but any in-flight tool call/response is aborted, which reads to the user as the session "crashing." One of the relaunches also produced a real error: two backend processes were spawned concurrently for the same relaunch and one failed with "Failed to save config with lock: Error: Lock file is already being held" (same signature as #27366, though that one is Windows ARM64/Bun-specific — this is Linux x64 via VS Code Remote/WSL2, no freeze, no crash exit code).

I ruled out: OOM (12GB+ free throughout), Extension Host crash/restart (same PID the whole time, confirmed via ps and remoteexthost.log), remote server disconnect (same PID), and large Markdown previews (none open during 2 of the 3 incidents).

What Should Happen?

The Claude Code chat panel should keep the backend process for an active session running continuously while the panel/tab exists, regardless of internal maintenance the extension performs (auth/token refresh, config saves, etc.).

If the extension does need to recycle the backend process for some internal reason, it should:

1. Never do so while a response is actively streaming (mid-turn) — wait for the current turn to finish, or resume seamlessly without dropping the in-flight tool call/response.
2. Never spawn two backend processes concurrently for the same relaunch — this is what causes the "Failed to save config with lock: Error: Lock file is already being held" error and leaves one process to die.
3. Not tear down unrelated, independent chat channels/tabs together when only one triggered the cycle (incidents #2 and #3 closed two separate tabs at the exact same instant).

At minimum, this recycling should be invisible to the user — no aborted in-flight response, no visible "closing" of the session.

Error Messages/Logs

**Incident #1 — 11:54:06 (tied to a tab switch, single channel)**

11:54:06.607  Closing Claude on channel: xf8cct13ric
11:54:06.609  [uds-messaging] Shutting down
11:54:06.612  LSP server manager shut down successfully
11:54:06.633  Cleaned up session snapshot
11:54:10.812  webview -> {"type":"init"}
11:54:10.891  webview -> {"type":"list_sessions_request"} / {"type":"get_session_groups"}
11:54:12.137  Spawning Claude with SDK query function ... resume: <session id>


**Incident #2 — 11:59:29 (two channels simultaneously, no preceding trigger, mid-stream)**

11:59:27.547  Stream started - received first chunk   <- active response in progress
11:59:29.163  Closing Claude on channel: xteawcinm6     <- this session
11:59:29.164  Closing Claude on channel: 7qaagyk2217    <- a second, unrelated open tab
11:59:29.679  Closing Claude on channel: 7qaagyk2217    (duplicate close)
11:59:31.161  Closing Claude on channel: xteawcinm6     (duplicate close)

Backend process count dropped to 0 for ~76s before the next relaunch.

**Incident #3 — 12:17:39 (two channels simultaneously, no preceding trigger, ~1 min full outage, config lock error on relaunch)**

12:17:39.909  Closing Claude on channel: rb3j8khe9wd
12:17:39.911  Closing Claude on channel: c46qrko0jgk
12:17:39.944  [uds-messaging] Shutting down (x2)

Backend stayed down for a full minute (12:17:49 → 12:18:49) until the user reopened the tab. On relaunch, two `claude` processes were spawned almost simultaneously and one logged:

12:18:49.570  [ERROR] Failed to save config with lock: Error: Lock file is already being held

That process died within ~15s; the other survived.

**What did NOT show any error at any of these timestamps** (checked to rule out VS Code-level causes):
- `remoteexthost.log`, `remoteagent.log`, `ptyhost.log` — completely silent, no restart/unresponsive/reconnection entries
- `ps` — Extension Host PIDs (204, 2765) and the remote server PID never changed across all 3 incidents

Timing between incidents: #1→#2 = 5m23s, #2→#3 = 17m50s (not a fixed interval).

Related: anthropics/claude-code#27366 shows the exact same "Failed to save config with lock: Error: Lock file is already being held" signature from a double-spawn, but on Windows ARM64/Bun with a full UI freeze + exit code 3 — different platform/symptom, possibly same root cause in the relaunch logic.

Steps to Reproduce

I don't have a fully deterministic reproduction — 2 of the 3 incidents happened with no user action at all. What I can share is the conditions present every time it occurred:

1. VS Code Remote (Linux/WSL2 remote server), two VS Code windows open simultaneously against the same remote host, each with at least one Claude Code chat tab open (so at least 2 chat channels active across the two windows at all times).
2. Org-managed deployment: policy-limits.json present with active restrictions, "Fast mode disabled by your organization" logged repeatedly.
3. A long-running session (25+ minutes) with ongoing back-and-forth tool use (Bash, Read, etc.) — not idle.

The one incident I could tie to a specific action:

• Switch away from the active Claude Code tab to a different editor tab while Claude is idle/between turns → the panel closes and relaunches the backend process on return (~6s later), auto-resuming the same session.

The other two incidents had zero preceding trigger in any log (no webview message, no settings change, no VS Code-level event) — one happened mid-response-stream, the other while idle. Both closed two independent chat channels/tabs at the same instant, suggesting a shared internal timer or resource is involved rather than a per-tab action.

Happy to share the raw Claude VSCode.log excerpts (both windows) and a lightweight watchdog journal I ran (polling ps/logs every 15s) that captured all 3 occurrences with timestamps, if that helps narrow down the trigger.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.233

Platform

Operating System

Linux (WSL2)

Terminal/Shell

N/A — via VS Code Remote (bash dans le terminal intégré VS Code)

Additional Information

_No response_