WSL2 repeatedly OOM-crashes (systemd killed) during multi-project Claude Code workflow/skill-generation task

Environment

• Claude Code version: 2.1.263 (Linux x64, running inside WSL2)
• WSL version: 2.5.9.0, kernel 6.6.87.2-microsoft-standard-WSL2
• Distro: Ubuntu on WSL2
• Host: Windows 11 Pro, 12 logical CPUs, 32GB RAM
• WSL2 memory limit at the time: default (~15GB, no .wslconfig present)

What happened

I asked Claude Code to generate skills for my project. At the time, the session had ~9 internal project directories open (a multi-repo workspace), and the code-modernization community plugin (with multi-agent workflow scripts) was installed.

Shortly after issuing the request, the WSL2 VM crashed repeatedly via OOM kill 4 times within about 3 minutes (08:56, 08:58:03, 08:58:44, 08:59:24). Each time, the kernel oom-killer killed systemd (pid 1's child) and sd-pam, which brought down the entire WSL instance (Docker containers included).

Evidence collected

• journalctl -k showed repeated Out of memory: Killed process ... (systemd) and (sd-pam) events, each preceded by containerd invoked oom-killer / V8Worker invoked oom-killer.
• The oom-killer's process-table dump at the time of the crash showed approximately 168 separate processes all named MainThread (the default Python main-thread name), collectively consuming ~13.5GB of RSS -- this dwarfed every other process (docker containers, postgres, redis, dotnet apps combined were <1GB).
• I could not identify the exact parent command/tool that spawned these, because bash history did not persist across the crash and the WSL instance kept crashing again while investigating live (it crashed 2 more times during the investigation itself).

Suspected cause

It looks like a Claude Code tool invocation (possibly during multi-agent/workflow orchestration across multiple project directories, or a plugin-provided workflow script) spawned a large number of short-lived processes without bounding concurrency or ensuring cleanup, causing them to pile up simultaneously instead of running sequentially/bounded, exhausting the WSL VM's memory ceiling almost instantly and repeatedly (crash-loop).

Ask

• Please investigate whether any Claude Code tool/workflow path (subagents, Skill/plugin execution, or the code-modernization marketplace plugin) can spawn unbounded concurrent child processes without a concurrency cap or guaranteed cleanup.
• Consider adding a safeguard (max concurrent subprocess limit, or memory-aware backoff) for tool executions that fan out across multiple project directories at once.

Impact

Full WSL2 VM crash (not just the offending process), taking down unrelated Docker containers and requiring a full wsl --shutdown + restart to recover.