Bash tool result delayed ~106 minutes inside a background subagent, no error/retry involved

Claude Code version: 2.1.217
Platform: Linux (WSL2), 6.6.87.2-microsoft-standard-WSL2

Summary

Running 4 Agent (subagent_type: general-purpose) tasks in parallel in the background, each subagent's first Bash tool call (a plain mkdir -p) took 328–350 seconds to return across all 4 subagents. One of the four subagents additionally had a later Bash call — a small local Python script with zero network/file-download I/O, just validating 6 already-on-disk JSON files — whose tool_use was emitted at 17:10:13.526Z and whose tool_result wasn't recorded until 18:56:40.037Z: a 106-minute gap. The eventual result was completely normal (no error, is_error: false, correct stdout, no indication of a retry or backoff) — it just took that long to come back.

The other 3 subagents running the same workload pattern (fetch a handful of items via an MCP tool, save to files, run a local validation/aggregation script) completed in 10–12 minutes each.

Reproduction context

• Launched via the Agent tool, 4 concurrent general-purpose subagents, each doing: several MCP tool calls (repo_pull_request_thread from a custom Azure DevOps MCP server) batched 2-3 at a time, Write a handful of small JSON files, then one Bash call to validate/aggregate them.
• All MCP tool calls returned normally (seconds to low-single-digit minutes, consistent with the known ~120s MCP-call-to-background-execution threshold).
• The anomalous delays were specifically on Bash tool calls with no external I/O — a directory creation and a local JSON-parsing loop over files already on disk.

Evidence

Extracted by diffing consecutive JSONL transcript entries' timestamp fields for the 4 subagent transcripts (~/.claude/projects/<project>/subagents/agent-<id>.jsonl):

Batch B transcript (the 2h5m outlier):
  line 6  (Bash tool_use, "mkdir -p ...")        16:53:43.123Z
  line 7  (tool_result)                          16:59:27.727Z   [+344s]
  ...
  line 47 (Bash tool_use, local python validation loop, no I/O)  17:10:13.526Z
  line 48 (tool_result)                          18:56:40.037Z   [+5787s / 106min]
  content of line 48's result: "2208641 OK, threads: 9\n2208538 OK, threads: 13\n..."
    (correct, unremarkable output — not an error, not evidence of a retry)

Batches A, C, D (10-12min total each) each independently showed the same
~330-350s stall on their first ("mkdir -p") Bash call, but no comparable
mid-run stall.

Total subagent wall-clock durations (from the completion notifications' usage.duration_ms):

• Batch A: 644,023 ms (~10.7 min)
• Batch C: 692,376 ms (~11.5 min)
• Batch D: 670,280 ms (~11.2 min)
• Batch B: 7,415,706 ms (~123.6 min) ← outlier

Expected behavior

A Bash tool call to a trivial local command (mkdir -p, or a short Python script reading a few KB of already-saved JSON) should return in well under a second to a few seconds, regardless of how many sibling subagents are running concurrently.

Actual behavior

• Baseline overhead: every subagent's first Bash call was delayed ~5.5–6 minutes, consistently across all 4 concurrent subagents — suggests contention or cold-start cost proportional to concurrent subagent count.
• One subagent had a single Bash call stall for 106 minutes with no error, retry, or unusual output — just an extremely delayed tool_result.

Impact

This was running as a background task for a scheduled daily digest, so it didn't block interactive use, but a routine intended to complete before the user starts their workday took over 2 hours end-to-end because of this single stall — unpredictable enough to undermine the "runs unattended every morning" use case.

Suspected area

Bash tool execution/scheduling in the subagent sandbox, likely related to resource contention when multiple subagents are launched concurrently — not the MCP server or the calling logic (all MCP calls behaved normally in the same run).