[BUG] Claude Code VS Code extension leaks worker processes when creating new chats

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?

Summary

The Claude Code VS Code extension spawns --model default worker processes that are never terminated when chats are closed or new chats are created. Over time, these orphaned processes accumulate and consume all available system memory, eventually triggering the Linux OOM killer.

Environment

• Host OS: Debian 12 (running in QEMU VM)
• RAM: 24GB + 1GB swap
• Code Server: 4.99.3
• Claude Code Extension: 2.0.75 (linux-x64)
• Extension Path: ~/.local/share/code-server/extensions/anthropic.claude-code-2.0.75-linux-x64

Process Accumulation Evidence

After creating 1 chat (3 processes):

PID       CPU  MEM   ARGS
1964160   9.7  1.9   claude ... --model default --max-thinking-tokens 0 ...
1964201   7.6  1.8   claude ... --model default --max-thinking-tokens 0 ...
1964367  13.9  1.6   claude ... --model opus --max-thinking-tokens 31999 --mcp-config {...}

After creating 2 chats (4 processes):

PID       CPU  MEM   ARGS
1964160   5.7  1.5   claude ... --model default ...  ← kept from chat 1
1964201   4.3  1.5   claude ... --model default ...  ← kept from chat 1
1965147  20.2  1.8   claude ... --model default ...  ← NEW
1965311  24.4  1.9   claude ... --model opus ...     ← replaced

After creating 3 chats (5 processes):

PID       CPU  MEM   ARGS
1964160   3.2  1.5   claude ... --model default ...  ← kept
1964201   2.4  1.5   claude ... --model default ...  ← kept  
1965147   4.5  1.5   claude ... --model default ...  ← kept
1965938  22.1  1.8   claude ... --model default ...  ← NEW
1966105  29.6  1.9   claude ... --model opus ...     ← replaced

Pattern

| Chats Created | Total Processes | Default Workers (leaked) | Opus Main |
|---------------|-----------------|--------------------------|-----------|
| 1 | 3 | 2 | 1 |
| 2 | 4 | 3 | 1 |
| 3 | 5 | 4 | 1 |
| N | N + 2 | N + 1 | 1 |

Impact

OOM Event

After running Code Server with the Claude Code extension for ~1 month with normal usage (creating new chats for different features/tasks), the system accumulated 40+ claude processes:

Dec 31 07:59:19 kernel: claude invoked oom-killer: gfp_mask=0x140cca(GFP_HIGHUSER_MOVABLE|__GFP_COMP)
Dec 31 07:59:19 kernel: Free swap  = 0kB
Dec 31 07:59:19 kernel: Out of memory: Killed process 716 (node) total-vm:15253416kB, anon-rss:3512728kB

The kernel logs showed 40+ claude processes at the time of the OOM event, each consuming ~330-390MB RAM:

[1464549]  claude    18658989    85671   ← ~330MB each
[1464558]  claude    18724526    84225
[1464576]  claude    18699949    84265
... (40+ more processes)

Memory Impact

• Each leaked worker: ~380MB RAM
• 40 chats over a month: ~42 processes × 380MB = ~16GB consumed by orphaned processes
• Combined with node processes and other services: exceeded 24GB RAM + 1GB swap

What Should Happen?

When a chat is closed or a new chat is created, the worker processes associated with the previous chat should be terminated.

Error Messages/Logs

Steps to Reproduce

1. Open Claude Code extension in Code Server (or VS Code)
2. Start a new chat
3. Close the chat or click "New Chat" to start another conversation
4. Repeat step 3 several times
5. Observe process accumulation with ps aux | grep claude

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude Code Extension: 2.0.75 (linux-x64)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

Possibly Related

• Issue #11122 (closed) discussed CLI process accumulation, but this is specifically about the VS Code extension's chat lifecycle management

Additional Context

The leaked processes are identifiable by --model default and --max-thinking-tokens 0 flags. The active chat's main process uses --model opus (or other selected model) with --max-thinking-tokens 31999 and includes --mcp-config.

This suggests the extension spawns "support" worker processes for each chat but only terminates the main model process when switching chats, leaving the workers orphaned.