[BUG] Process explosion with sub-agents causes dotnet segfaults and session crashes

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?

Claude Code sessions with sub-agents spawn excessive dotnet processes (80-160 processes per active agent instead of 2-5), leading to continuous dotnet segmentation faults, zombie process accumulation, system load exceeding 60+, and session crashes with exit code 1. After crashes, 400-500+ orphaned dotnet processes remain and don't clean up automatically.

What Should Happen?

• Each active sub-agent should spawn 2-5 dotnet processes
• With 3-6 active sub-agents, total process count should be 10-30
• Sessions should run stably without crashes
• Processes should terminate cleanly when agents complete or sessions end

Error Messages/Logs

**Session crash message:**
  [process exited with code 1 (0x00000001)]
  You can now close this terminal with Ctrl+D, or press Enter to restart.

  **Continuous dmesg segmentation faults:**
  [09:24:46 2026] traps: dotnet[23975] general protection fault ip:763e9b59050f sp:7ffff82e1590 error:0 in libc.so.6[763e9b590000+156000]
  [09:24:46 2026] dotnet: dotnet: potentially unexpected fatal signal 11.
  [09:24:46 2026] CPU: 0 PID: 23975 Comm: dotnet Not tainted 6.6.87.2-microsoft-standard-WSL2 #1
  [09:24:46 2026] WSL (24074 - CaptureCrash): Capturing crash for pid: 1, executable: !usr!share!dotnet!dotnet, signal: 11, port: 50005

  **System load during incident:**
  
  $ uptime
  09:24:51 up 55 min, 0 user, load average: 44.17, 27.30, 13.66
  # During crash: load average: 62.06, 31.99, 17.54

Steps to Reproduce

1. Environment setup:

• WSL2 Ubuntu 24.04 with dotnet 9.0.306 installed
• 24GB RAM allocated to WSL2, 256GB swap

1. Start Claude Code session:

claude

1. Allocate sub-agents:

• Request work requiring 12 sub-agent allocation with 3-6 actively working

1. Monitor in separate terminal:

watch -n 2 'ps aux | grep -c dotnet'

1. Observe:

• Process count rapidly grows to 400-500+ (instead of 10-30)
• System load climbs to 60+ (on 12-core system)
• Continuous segfaults appear in dmesg | tail -f | grep dotnet
• Session crashes with exit code 1

1. Check zombie processes:

ps aux | grep dotnet | wc -l
# Shows 453-553 orphaned processes

Diagnostic commands showing the issue:
# Parent process spawned 502 children (should be ~12-20)
$ ps -eo ppid | sort | uniq -c | sort -rn | head -3
502 19548

# Process count INCREASES even after killing parent
$ kill -9 19549
$ sleep 2
$ ps aux | grep dotnet | wc -l
553 # Increased from 502!

# Manual cleanup required
$ pkill -9 dotnet
$ ps aux | grep dotnet | wc -l
2 # Finally cleaned up

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

N/A - Not tested with earlier versions

Claude Code Version

$ claude --version 2.1.11 (Claude Code)

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

WSL (Windows Subsystem for Linux)

Additional Information

Dotnet Environment

$ dotnet --version
9.0.306

$ dotnet --list-runtimes
Microsoft.AspNetCore.App 9.0.10 [/home/donald/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 9.0.10 [/home/donald/dotnet/shared/Microsoft.NETCore.App]

System Configuration

• Host: Windows 11 with 64GB physical RAM
• WSL2 RAM allocation: 24GB (carefully balanced to prevent Windows crashes)
• Swap: 256GB on SSD
• CPU: 12 cores
• Kernel: 6.6.87.2-microsoft-standard-WSL2

Key Observations

This is a process spawn leak, not a memory leak:

• RAM usage was acceptable (21GB free out of 24GB)
• Issue is excessive process count causing kernel-level crashes

Process explosion details:

• Expected: 2-5 processes per active agent
• Actual: 80-167 processes per active agent
• Session had 3-6 agents actively working (12 allocated)
• Total: 502 dotnet processes (should be 10-30)

Zombie process behavior:

• Processes don't terminate when parent Claude session dies
• Process count sometimes increases after killing parent (502 → 553)
• Requires manual pkill -9 dotnet cleanup

Attempted Mitigations (Did NOT help)

Increased virtual memory limits:
sudo sysctl -w vm.max_map_count=524288 # Doubled from default

Configured dotnet GC environment:
export DOTNET_GCHeapHardLimit=0x400000000
export DOTNET_GCConserveMemory=5
export DOTNET_EnableWriteXorExecute=0
export DOTNET_ThreadPool_UnfairSemaphoreSpinLimit=6

Related Issues

This shares characteristics with but is distinct from:

• #7020 (Memory leak with sub-agents on macOS) - Similar symptoms but memory-focused, not process count
• #8706 (Resource exhaustion in WSL2 with Sonnet 4.5) - Similar platform but disk I/O focused
• #5682 (Freezing with multiple sub-agents in WSL2) - Similar platform but freezing, not crashes

Key difference: This issue involves dotnet-specific process explosion (80-160x normal) with segmentation faults, not reported in other issues.

Questions

1. Is dotnet 9.x officially supported in WSL2, or should users use dotnet 8 LTS?
2. Has Claude Code 2.1.11 been tested with dotnet 9.0.306 in WSL2?
3. Is there a documented maximum sub-agent count for WSL2 environments?
4. Are there known process cleanup issues with sub-agents in WSL2?

Impact

Severity: Critical

System Stability:

• Work in progress lost when sessions crash unexpectedly
• Multiple concurrent sessions crash together
• System becomes unresponsive (load 60+ on 12-core system)
• Requires WSL2 restart to fully clean up
• Manual process cleanup required after each crash (pkill -9 dotnet)
• Blocks effective use of sub-agents in WSL2 environments

Operational:

• Issue occurs regularly, not an isolated incident
• Pattern suggests widespread impact on WSL2 users with sub-agents
• 453-553 zombie processes accumulate after crashes, requiring manual intervention

Resource Usage:

• Process multiplication: 80-167x expected count (502 processes for 3-6 active agents)
• Zombie processes continue running after parent session terminates
• Clear correlation observed between process explosion and API request patterns and token usage