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.

Start by reproducing the reported multi-project workflow with subagents, Skill/plugin execution, and the code-modernization marketplace plugin in WSL2, while observing child-process counts and memory use. Trace which tool or workflow entry point creates the MainThread processes, then verify that concurrency and cleanup are bounded and that the crash-loop scenario no longer occurs.

Rédigé par le modèle d'indexation à partir du texte de l'issue.