[BUG/feature] Add Windows-aware concurrency cap for parallel Agent dispatches (msys fork corruption)

Summary

On Windows with Git Bash (msys2), dispatching large numbers of parallel sub-agents in a single message (via many Agent tool calls) deterministically corrupts msys's emulated fork(), after which every subsequent Bash command fails until the parent bash is killed. Claude Code currently has no built-in concurrency cap on parallel Agent dispatches, which makes this trivial to hit on any portfolio-audit-style workflow.

What happened

During a task-forge portfolio audit, I asked Claude to generate plan files for 101 open ideas. Claude dispatched roughly 100 parallel Agent sub-agents in a single message (correctly, per the tool docs' guidance to maximize parallel tool calls). Each sub-agent runs its own Bash invocations.

Within a minute or two, the parent session's msys began failing forks:

0 [main] bash ... dofork: child -1 - forked process ... died unexpectedly, retry 0, exit code 0xC0000142, errno 11
/etc/profile: fork: retry: Resource temporarily unavailable

After that point, every Bash tool call failed the same way. Claude documented the issue and suggested the user restart the session, but by then the audit was unrecoverable.

Why this is a Claude-Code-level problem

The underlying fork fragility under concurrent load is a well-documented Cygwin/msys2 limitation — Claude Code can't fix that. But two things are in Claude's control:

1. No concurrency cap on Agent dispatches. The Agent tool description actively encourages parallel use (\"make all independent tool calls in parallel\"). On Linux/macOS this is fine. On Windows/msys, it's a loaded gun — the more parallel agents, the higher the chance that at least one fork in the batch wedges the parent.
2. No platform-aware default. The pr-pipeline slash command caps itself at --concurrency 4 because of unrelated AWS SSO throttling. A similar default for Agent on Windows (empirically ~10-15 before msys starts degrading, depending on fork rate) would have prevented this.

Requested change

Option A (preferred): A platform-aware default concurrency cap on Agent — on Windows, silently cap parallel dispatches at e.g. 10, with a CLI flag or settings.json key to raise it. Linux/macOS default stays uncapped.

Option B: At minimum, document the msys fork ceiling in the Agent tool description and in the Windows setup docs, so people on Windows know not to dispatch \"100 agents in parallel\" without batching.

Option C (complementary): Detect the msys fork-fail signature (0xC0000142 / STATUS_DLL_INIT_FAILED in Bash stderr) and, instead of continuing to dispatch, surface a visible warning and restart the bash shell with a new session.

Reproducibility

• High. On Windows 11 + Git Bash, dispatching 30+ Agent subagents in one message reliably degrades fork performance within a minute or two, and 100+ reliably wedges it.
• WSL / Linux / macOS are unaffected (real fork()).

Environment

• OS: Windows 11 Enterprise 10.0.26100
• Shell: Git Bash (msys2)
• Claude Code version: current at time of filing (2026-05-11)
• Reproduction: task-forge portfolio audit with 100+ ideas, or any workflow that spawns 30+ parallel Agent subagents in one message

Related issues

• #47438 — same underlying fork failure, but in a single-Bash context (not parallel-agent load). This request is specifically about preventing Claude Code from causing the degradation through uncapped parallelism.
• #24255 — closed, also msys fork.

Workaround (until fixed)

• Split heavy batch work into separate headless claude -p invocations, each handling 10-15 items.
• Or, serialize the Agent dispatch inside a single session (one-at-a-time), trading throughput for stability.