[BUG] Bash tool timeout backgrounds a command instead of cancelling it — contributed to multi-hour VM disk-saturation incidents under concurrent subagent load

Preflight Checklist

• [x] Searched existing issues — closest are #19459 and #15487 (both closed, zero maintainer engagement, auto-closed for inactivity)
• [x] Single bug report
• [x] Using latest version (2.1.233)

What's Wrong?

Bash tool timeout: parameter doesn't cancel the command when it fires — it silently backgrounds it and lets it keep running. Confirmed at the OS level with strace: a command given timeout: 3000 kept running 16 seconds past the point the tool reported "timed out."

On a real VM this contributed to two multi-hour disk-saturation incidents (176.2 MB/s and 176.8 MB/s, pinned flat, hours each) under concurrent subagent load, requiring a manual VM stop/start both times — it did not recover on its own.

What Should Happen?

A timeout:-driven Bash call that fires should either actually kill the process, or the tool result should make unmistakably clear that the process is still running and consuming resources — not just "moved to background" as a routine, easy-to-ignore status.

Error Messages/Logs

Tool result text (application layer):

Command did not complete within its 3s timeout and was moved to the background (ID: bs1kcupl9).

strace -f -tt -e trace=execve,exit on the same process (OS layer, independent confirmation):

15:26:18.777439 execve("/usr/bin/xargs", ["xargs", "-0", "cat"], ...)
     [agent released from waiting at 15:26:21 -- the 3s mark]
15:26:37.xxxxxx  +++ exited with 0 +++   [~16s after the timeout fired]

Steps to Reproduce

1. Run any real command that takes >3s over an uncached directory, e.g.:

find /some/large/dir -type f -print0 | xargs -0 cat > /dev/null 2>&1

1. Have Claude Code call it via the Bash tool with timeout: 3000
2. Note the result says "moved to the background," not "cancelled" or "killed"
3. Independently confirm with strace -f -e trace=execve,exit attached to the claude process — the underlying process is still running well after the timeout fired

Claude Model

Opus

Is this a regression?

I don't know

Claude Code Version

2.1.233

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other (headless, via -p/--output-format stream-json)

Additional Information

• We think this is a contributing factor to real concurrent-subagent disk-saturation incidents, not the whole story — under real load with CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS left at its default (20) rather than scaled to the machine, this compounds. We could not get a single unprimed agent to reproduce runaway pile-up on its own across five separate attempts — our best read is that the real danger is many concurrent, individually-reasonable subagents each backgrounding their own timed-out work, not any single agent behaving badly.
• Related, same genus: #15487 (24 parallel subagents, 17.3x disk I/O spike, full VPS lockup) and #19459 (redundant per-session file I/O — we specifically re-checked #19459's named findings on 2.1.233 and they don't reproduce here, noting in case anyone assumes that one's still current).
• Full writeup with all evidence: [link to docs/disk-io-investigation-2026-08.md in our repo, if we want to reference it]