[BUG] VS Code: archiving the open session resumes the next one, so archiving N idle sessions leaves N new claude processes running

Summary

In the VS Code extension, archiving the session that is open in the panel makes the panel open the next session in the list, and opening it resumes it: a new claude process starts for a session that had none. Archiving that one does not stop its process, and it opens and resumes the next one. Archiving idle sessions one after another therefore starts one process per archived session, and none of them exits.

Archiving 51 sessions over two minutes left 49 new idle claude processes of about 230 MiB RSS each (about 11.5 GiB). They stayed alive, with no child processes, until killed by hand.

Environment

• Claude Code VS Code extension 2.1.283 (native binary, --output-format stream-json)
• VS Code 1.139.1, Remote-SSH to a Linux host (Debian 13, kernel 6.12)
• Remote Control connected: each process reattaches to a persisted bridge session
• 55 past sessions in the project

Steps to reproduce

1. Open a project with many past, idle sessions (no claude process running for them).
2. In the Claude panel, archive the open session. The panel opens the next session in the list.
3. Archive that one too, and repeat.
4. Count processes: ps -eo args | grep -c 'native-binary/claude .*--resume='

Expected

• Archiving a session starts no process.
• A process that is running for an archived session is stopped.

Actual

Each archive is followed by a transcript open and a launch_claude with resume for the next session. No webview message closes or stops any channel. From exthost*/Anthropic.claude-code/Claude VSCode.log, with session ids replaced:

20:57:39.963 webview → archive_session      sessionId=<A>
20:57:40.028 webview → get_session_request  sessionId=<B> purpose=transcript_open
20:57:40.266 webview → launch_claude        resume=<B> freshStartIfUnresumable=false
20:57:40.303 Spawning Claude with SDK query function … resume
20:57:40.889 [bridge:repl] Reattaching to persisted bridge session <bridge-B> at seq 234 (fresh-mint fallback, restored_owner_match)
20:57:41.881 [bridge:repl] Inbound control_request subtype=end_session
20:57:41.881 [bridge:repl] Sent control_response for end_session request_id=<…> result=error
20:57:43.059 webview → archive_session      sessionId=<B>
20:57:43.080 webview → get_session_request  sessionId=<C> purpose=transcript_open
20:57:43.252 webview → launch_claude        resume=<C> freshStartIfUnresumable=false
…

Between 20:57 and 21:00 the log shows 53 archive_session requests and 49 launch_claude resumes. Afterwards:

• 52 claude processes were children of the one extension host: 12.1 GiB RSS in total, 225–240 MiB each for the idle resumed ones.
• All 51 processes started with --resume belonged to archived sessions.
• Right after reattaching to its bridge session, a resumed process received an inbound end_session control request and answered result=error. This happened 35 times, 34 of them during the burst. So the remote side's attempt to end these sessions did not stop them either.
• When the processes were stopped with SIGTERM (exit code 143), each logged [remote-bridge] Torn down (archive=200), and the extension logged Claude Code process exited with code 143 for every channel.

Related

• #90712: archiving does not stop the session process (Desktop)
• #96681: archived sessions keep running in VS Code, and unarchiving starts a second process

This report differs from both: archiving also starts processes, for sessions that were not running, one for each session archived in sequence.