Bash tool silently kills commands after ~80s and discards all output (timeout parameter ignored)
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
The Bash tool has an internal hard timeout of ~80 seconds that silently kills commands and discards all captured stdout/stderr - including output that was already written before the timeout fired. The explicit timeout parameter is completely ignored. The tool reports Tool ran without output or errors with an apparent exit code of 0, making it look like the command either succeeded silently or never ran.
This is different from:
- #25881 (10-minute ceiling) - our threshold is ~80s, far below any configured limit
- #28408 (timeout not enforced on pipes) - our timeout fires when it shouldn't
- #30583 (nested CLI deletes output file) - our issue is purely time-based, no nested CLI involved
Reproduction
Minimal reproduction using sleep + echo:
# Works (80 seconds) - output captured correctly:
echo "BEFORE"; sleep 80; echo "AFTER"
# Result: "BEFORE\nAFTER"
# Broken (81 seconds) - ALL output silently discarded:
echo "BEFORE"; sleep 81; echo "AFTER"
# Result: "Tool ran without output or errors"
The BEFORE string was written to stdout immediately, but when the internal timeout fires at ~80s, even already-flushed output is lost.
Setting the timeout parameter explicitly makes no difference:
{
"command": "echo BEFORE; sleep 81; echo AFTER",
"timeout": 300000
}
Still returns Tool ran without output or errors at ~80 seconds. The 300000ms (5 minute) timeout is ignored.
Threshold
Binary search places the cutoff between 80 and 81 seconds:
| sleep duration | timeout param | output captured? |
|---------------|--------------|-----------------|
| 60s | default | yes |
| 75s | default | yes |
| 80s | default | yes |
| 81s | default | no - all output lost |
| 85s | default | no |
| 90s | default | no |
| 81s | 300000 | no |
| 115s | 120000 | no |
| 125s | 130000 | no |
Impact
This breaks any command that takes more than 80 seconds:
- Deploy scripts (docker build + push + kubectl rollout)
- Large test suites
- Database migrations on real data
- Docker builds with uncached layers
The silent discard is the most dangerous part - the tool reports success with no output, so the natural response is to re-run the command. In our case this caused triple-deploys before we identified the root cause.
Additionally, subprocesses spawned by the killed command (e.g. docker build) may continue running in the background, so operations may partially complete despite the tool reporting nothing.
Environment
- Claude Code: 2.1.76
- OS: Linux 6.17.13+deb14-amd64 (Debian)
- Shell: bash
- Running via Claude Agent SDK (Discord bot), not the TUI
Workaround
We built an MCP server that spawns commands via Node.js child_process.spawn directly, bypassing the Bash tool entirely. MCP tool calls go through JSON-RPC and are not subject to the same internal timeout. This works reliably for commands of any duration.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗