Parallel Agent tool uses count shows 0 when running 5+ agents concurrently

Environment

• Claude Code version: 2.1.90
• Model: Opus 4.6 (1M context)
• OS: macOS Darwin 25.3.0
• Terminal: Warp 0.2026.03.25

Bug Description

When launching 5 Agent tool calls simultaneously in a single message (all subagent_type: "Explore"), the CLI displays 0 tool uses for every agent after completion. The agents actually executed multiple tools (Read, Grep, Glob, etc.) and returned complete research results (thousands of characters each).

Steps to Reproduce

1. In a single message, send 5 parallel Agent tool calls, all with subagent_type: "Explore"
2. Each agent scans a different area of the codebase
3. Wait for all 5 to complete

Actual Result

5 Explore agents finished (ctrl+o to expand)
├─ 掃描 LIFF 頁面路由和實際頁面 · 0 tool uses
├─ 掃描 API routes 和 Edge Functions · 0 tool uses
├─ 掃描任務狀態和業務流程 · 0 tool uses
├─ 掃描桌面 Web 功能和 views · 0 tool uses
└─ 掃描推播通知和 cron 系統 · 0 tool uses

Expanding each agent shows full research reports with extensive file reads and search results — clearly not 0 tool uses.

Expected Result

Each agent should display its actual tool use count, e.g.:

├─ 掃描 LIFF 頁面路由和實際頁面 · 23 tool uses

Control Group (same session, later)

Launching 3 agents in parallel (2 Explore + 1 Plan) in the same session correctly shows tool use counts:

├─ 探索甘特圖現有實作 · 37 tool uses
├─ 探索權限和日期確認機制 · 37 tool uses
└─ 設計甘特圖拖曳方案 · 37 tool uses

Analysis from Binary Reverse Engineering

Traced the data flow through the compiled binary:

1. Nz1() counts tool_use content blocks from agent messages — pure function, no race condition
2. EE_() calls Nz1(messages) on agent completion → returns totalToolUseCount
3. uE_() stores result (including totalToolUseCount) into task state
4. Display component reads: q.result?.totalToolUseCount ?? q.progress?.toolUseCount

Since ?? does not fall through on 0 (only on null/undefined), if result.totalToolUseCount is 0, the fallback to progress.toolUseCount never triggers.

The counting function Nz1() is pure, so the likely root cause is that the messages array is not correctly populated when Nz1 runs under high parallelism (5 agents), possibly due to shared mutable state or a buffer/queue issue that doesn't manifest at lower concurrency (3 agents).

Key Observation

• Data is NOT lost — agent results contain complete content
• This is purely a display/metrics bug in tool use counting
• The threshold appears to be between 3 and 5 concurrent agents