[FEATURE] Add `maxParallelAgents` Configuration Setting

Status Closed — not planned
Reported on v2.0.76
Maintainer reply None cached
Activity 7 comments · opened Dec 27, 2025 · closed Mar 4, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

Claude Code can spawn an unlimited number of parallel subagent processes, which can overwhelm resource-constrained systems (VPS, small servers) and cause complete system lockups requiring hard reboots.

On December 27, 2025, my server became completely unresponsive while using Claude Code. Investigation revealed that 24 parallel subagent processes were spawned within a 2-minute window, overwhelming the system's disk I/O.

System Specifications

Platform: Linode VPS
OS: Ubuntu (Linux 6.14.3-x86_64-linode168)
CPU: AMD EPYC 7642 48-Core Processor (2 vCPUs allocated)
RAM: 4GB
Swap: 4GB
Disk: 80GB SSD
Claude Code Version: 2.0.76
Model: claude-opus-4-5-20251101

Evidence of Parallel Agent Spawning

The following agent session files were all created/modified within the same 2-minute window (00:19-00:21):

-rw------- 1 root root 1786 Dec 27 00:19 agent-a961218.jsonl
-rw------- 1 root root 1956 Dec 27 00:19 agent-a3d5a00.jsonl
-rw------- 1 root root 2137 Dec 27 00:19 agent-ac1eb27.jsonl
-rw------- 1 root root 2318 Dec 27 00:19 agent-a27b0e8.jsonl
-rw------- 1 root root 2761 Dec 27 00:19 agent-a6d2e1a.jsonl
-rw------- 1 root root 1851 Dec 27 00:20 agent-aa5a497.jsonl
-rw------- 1 root root 1877 Dec 27 00:20 agent-a64b594.jsonl
-rw------- 1 root root 1881 Dec 27 00:20 agent-a2773a9.jsonl
-rw------- 1 root root 1910 Dec 27 00:20 agent-a23376a.jsonl
-rw------- 1 root root 1913 Dec 27 00:20 agent-a361ad1.jsonl
-rw------- 1 root root 1916 Dec 27 00:20 agent-a78ed9a.jsonl
-rw------- 1 root root 1945 Dec 27 00:20 agent-a2dab9c.jsonl
-rw------- 1 root root 3021 Dec 27 00:20 agent-a8aaf7d.jsonl
-rw------- 1 root root 3396 Dec 27 00:20 agent-a7c851c.jsonl
-rw------- 1 root root 3493 Dec 27 00:20 agent-a9f250b.jsonl
-rw------- 1 root root 3633 Dec 27 00:20 agent-afedd05.jsonl
-rw------- 1 root root 3961 Dec 27 00:20 agent-a8a897a.jsonl
-rw------- 1 root root 5384 Dec 27 00:20 agent-a09c5fe.jsonl
-rw------- 1 root root 1744 Dec 27 00:21 agent-a5ffb9b.jsonl
-rw------- 1 root root 1929 Dec 27 00:21 agent-ab9015c.jsonl
-rw------- 1 root root 1969 Dec 27 00:21 agent-ace58e4.jsonl
-rw------- 1 root root 2113 Dec 27 00:21 agent-a7eca68.jsonl
-rw------- 1 root root 3388 Dec 27 00:21 agent-a072cd8.jsonl
-rw------- 1 root root 4296 Dec 27 00:21 agent-a7ccb53.jsonl

System Impact

Linode monitoring captured the moment of lockup:

| Metric | Normal Average | At Lockup (12:20 AM) | Multiple |
|--------|----------------|----------------------|----------|
| CPU % | 7.59% | 42.77% | 5.6x |
| Disk I/O (blocks/s) | 8.83 | 152.80 | 17.3x |

The 17x disk I/O spike caused complete system unresponsiveness. No OOM killer activity was logged—the system locked up due to I/O saturation before memory limits were reached. A hard reboot was required.

Documentation Contradiction

The Claude Code documentation states:

"Subagents operate sequentially, not in parallel."

However, the evidence above shows either parallel execution — 24 agent files with overlapping timestamps within a 2-minute window — or, it's spawning so quickly that they're happening sequentially but as fast as the system can spawn them. This occurs when Claude issues multiple Task tool calls in a single response. _(The documentation is a little vague -- does "sequentially" in this instance mean that the agents are spawning one at a time -- completing its task before spawning another -- or, does it just mean that you're spawning all of the agents one after another as fast as you can?)_

Proposed Solution

Add a new configuration setting to ~/.claude/settings.json:

{
  "maxParallelAgents": 3
}

Suggested Behavior

| Setting | Value | Description |
|---------|-------|-------------|
| Default | 5 | Reasonable for most systems |
| Minimum | 1 | Forces sequential execution |
| Maximum | unlimited or -1 | Current behavior |

When the limit is reached, queue additional agent requests and execute them as running agents complete.

CLI Integration

claude config set maxParallelAgents 3
claude config get maxParallelAgents

Alternative Solutions

  1. maxAgentMemoryMB: Limit total memory allocated to all agents combined
  2. agentSpawnDelayMs: Add a minimum delay (in milliseconds) between spawning agents
  3. Auto-detection: Detect available system resources (CPU cores, free memory) and auto-limit accordingly
  4. Per-session limit: Allow setting limits per session via CLI flag: claude --max-agents 3

Priority

High - Significant impact on productivity

Feature Category

Configuration and settings

Use Case Example

A developer running Claude Code on a 4GB VPS asks Claude to analyze Apache access logs for suspicious patterns. Claude decides to spawn multiple parallel agents to:

  • Search for specific log patterns
  • Read configuration files
  • Check multiple log files simultaneously
  • Cross-reference IP addresses

Without limits, 20+ agents spawn simultaneously. Each agent:

  • Consumes memory (Node.js process overhead)
  • Writes to its own session file on disk
  • Competes for disk I/O bandwidth

On a small VPS with limited I/O bandwidth, this causes an I/O storm that makes the system completely unresponsive.

With maxParallelAgents: 3, the same task completes successfully (albeit slightly slower) without risking system stability.

Additional Context

Current Workaround

Until this feature is implemented, I've had to implement OS-level protections that affect all processes, not just Claude Code:

# /etc/security/limits.conf
root            soft    nproc           100
root            hard    nproc           150

This will hopefully cause the kernel to kill runaway processes rather than allowing system lockup, but it's a blunt instrument.

Impact

This issue makes Claude Code risky to use on small VPS instances for any task that might trigger parallel agent execution. Users have no way to prevent or limit this behavior, and the only recovery from a lockup is a hard reboot.

View original on GitHub ↗

7 Comments

github-actions[bot] · 8 months ago

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

Amadeus- · 8 months ago

Why does the system want to auto-close when there have been no comments and no one from anthropics has made any mention of having seen it.

Has anyone seen any of these issues being addressed by anthropics? Or, is it a waste of time to post anything?

audiovideoron · 8 months ago

Adding another data point from macOS Apple Silicon.

System: Mac mini M4 Pro, 24GB RAM, macOS 26.2 (25C56)

Symptoms: Complete system freeze requiring hard reboot. Not a kernel panic—the WindowServer watchdog timeout killed the display server after it became unresponsive for 40+ seconds.

Root cause from spindump analysis:

(blocked by compressor segment busy for thread Electron [94598])

Multiple parallel subagents exhausted available RAM. The macOS memory compressor couldn't keep up, causing threads to block waiting for compressed memory pages. WindowServer got caught in this blocking chain → system froze → watchdog triggered reboot.

Pattern: This has happened multiple times with different workloads:

  • Parallel subagents running Whisper (speech-to-text)
  • Orchestrator spawning many Task agents simultaneously
  • General parallel Task tool execution

Practical limits observed on 24GB M4 Pro:

  • ~5-6 parallel agents for light tasks (file ops, git)
  • ~3-4 for medium tasks (builds, linting)
  • ~2 for heavy tasks (Whisper, large file processing)

The maxParallelAgents setting would be very helpful. Even better would be workload-aware throttling—letting Claude Code detect memory pressure and queue rather than spawn.

github-actions[bot] · 7 months ago

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

maximedupre · 7 months ago

I confirm this would be useful.

Amadeus- · 7 months ago

I don't know why we even create issues here...if they're never going to respond to them.

github-actions[bot] · 7 months ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.