Bash tool intermittently takes minutes to return despite command finishing in <10ms

Description

Bash tool commands intermittently take anywhere from ~15 seconds to 4+ minutes to return, even though the underlying shell command completes in single-digit milliseconds once it actually starts running. This happens for arbitrary commands (ls, ps aux, wc -l, sample) on arbitrary paths (~/Documents, /Volumes, plain scratch files under ~/.claude/projects/...), so it isn't specific to any one command or filesystem location.

Environment

• Claude Code: 2.1.222
• OS: macOS 26.5.2 (Build 25F84)
• Hardware: MacBook Pro (Mac14,6), Apple M2 Max, 12 cores (8P+4E), 64 GB RAM
• Shell: bash, invoked via the Bash tool (not an interactive session)
• System was under real memory pressure during testing (~61/64 GB used) and had accumulated ~191 long-lived XPC helper processes since a 10-day-old boot — noted for completeness, but not established as causal since the same commands were never slow outside Claude Code on this same machine at the same time

Evidence

1. The delay is not in the command itself. Wrapping the command with its own internal timer shows the actual work finishes in <10ms, while the Bash tool call as a whole takes 15s–4min+ to return:

``
echo "START $(date +%H:%M:%S.%N)"; ls /Volumes >/dev/null; echo "DONE $(date +%H:%M:%S.%N)"
`
Output:
`
START 11:16:18.943536000
DONE 11:16:18.951673000
``
— but this call had been issued about 4 minutes earlier and only got moved to a background task after its 15s timeout elapsed. The gap is entirely between "tool call issued" and "the command's own clock starts," not inside the command.

1. Not filesystem/OS/sandbox related. The exact same commands, run in a plain interactive terminal on the same Mac at the same time, are never slow. This rules out macOS-level causes (TCC/Full Disk Access, Spotlight mds/mdworker indexing, stale network mounts, kernel-level fork/exec contention) since those would affect a plain terminal too.

1. Not the macOS sandbox (Seatbelt) filesystem containment. Direct controlled A/B test: two Bash tool calls issued at the same moment, one plain, one with dangerouslyDisableSandbox: true. The plain (sandboxed) call returned in 3ms; the unsandboxed call hung past its timeout — the opposite of what sandbox-containment-as-cause would predict. Separately, setting sandbox.filesystem.disabled: true in ~/.claude/settings.json and restarting the session did not prevent the hang from recurring on the very first command of the new session.

1. Not path-specific. Reproduced on ~/Documents, /Volumes, a local scratch file under the session's own working directory, ps aux (touches no filesystem path), and sample (a lightweight diagnostic tool — this one was actually killed after its timeout rather than backgrounded).

1. Possible but unconfirmed contributing factor: issuing many overlapping/backgrounded Bash tool calls in quick succession while investigating seemed to make the problem worse (a trivial local wc -l sat pending for several minutes during a burst of ~7 concurrent Bash calls). This suggests some kind of queue or concurrency bound in the tool-dispatch path that can back up, though this wasn't isolated from a clean baseline.

Impact

Bash tool commands are unpredictably slow — anywhere from instant to several minutes — independent of what the command does or which path it touches. This makes routine tool use unreliable and forces falling back to the background-task/polling workaround for what should be trivial, fast operations.

What would help

Any visibility into what happens between a Bash tool call being issued and the underlying shell process actually starting (an IPC round-trip, a sandbox-profile compilation/setup step, a concurrency queue, etc.) would help pin down where the multi-second-to-multi-minute gap is coming from.