BASH_DEFAULT_TIMEOUT_MS and BASH_MAX_TIMEOUT_MS environment variables are non-functional

[JoeOakhartNava]

Summary

The BASH_DEFAULT_TIMEOUT_MS and BASH_MAX_TIMEOUT_MS environment variables, which appear to be intended to control Bash tool timeout behavior, have no effect on the actual timeout ceiling. Regardless of their values, Bash tool calls are subject to a hard ~73s ceiling (with timeout: 600000) or ~48s ceiling (default).

Environment

• Claude Code CLI (tested across multiple v1.x releases)
• macOS (Darwin), also reported on Linux
• Bash tool calls via the Claude Code agent interface

Reproduction Steps

1. Set environment variables:

   export BASH_DEFAULT_TIMEOUT_MS=300000
   export BASH_MAX_TIMEOUT_MS=600000

2. Start a Claude Code session and issue a Bash tool call with a long-running command:

   # With timeout: 600000 parameter
   sleep 120

3. Observe that the command is killed after ~73 seconds with exit code 144 (SIGURG), despite:

   • BASH_DEFAULT_TIMEOUT_MS=300000 (5 minutes)
   • BASH_MAX_TIMEOUT_MS=600000 (10 minutes)
   • timeout: 600000 parameter on the tool call

4. Without the timeout parameter, the ceiling drops to ~48 seconds.

Expected Behavior

• BASH_DEFAULT_TIMEOUT_MS should control the default timeout for Bash tool calls when no timeout parameter is specified
• BASH_MAX_TIMEOUT_MS should control the maximum allowed timeout
• Setting timeout: 600000 on a Bash tool call should allow the command to run for up to 10 minutes (600 seconds)

Actual Behavior

• BASH_DEFAULT_TIMEOUT_MS has no effect on timeout behavior
• BASH_MAX_TIMEOUT_MS has no effect on timeout behavior
• The timeout parameter on Bash tool calls has a hard ceiling of ~73 seconds regardless of value
• Without timeout parameter, the ceiling is ~48 seconds
• Commands are killed via SIGURG (exit code 144 = 128 + 16)

Additional Notes

run_in_background does not isolate from SIGURG

Using run_in_background: true on Bash tool calls does not prevent the process from being killed by SIGURG. Background tasks are still subject to the same timeout ceiling and are killed when the timeout is reached.

Impact

This limitation affects any workflow that needs to run commands exceeding ~73 seconds, including:

• Test suites (common for projects with comprehensive test coverage)
• Build/compilation steps
• Database migrations
• Package installation
• CI status polling

Current Workarounds

Users must use nohup with file-based output capture in two separate Bash tool calls to work around this limitation:

Call 1 (launch — must exit immediately):

nohup bash -c 'long-running-command > /tmp/output.txt 2>&1; echo $? > /tmp/exit-code.txt' &

Call 2 (poll for completion):

while [ ! -f /tmp/exit-code.txt ]; do sleep 3; done && cat /tmp/output.txt

This workaround is fragile, requires managing temporary files, and the polling loop itself can be killed if the command takes too long.

Related

• The Bash tool documentation mentions timeout parameter with "max 600000" but this maximum is never achievable in practice
• Exit code 144 (128 + SIGURG) is the kill signal used by Claude Code for both timeouts and internal preemption, making it difficult to distinguish true timeouts from other cancellation reasons

[nicolasnoble]

Adding findings from our independent investigation (#34266) that may be useful:

Silent output discard (not just timeout)

The most dangerous aspect of this bug isn't the premature kill - it's that all captured stdout/stderr is silently discarded, including output written well before the timeout fires. The tool then reports Tool ran without output or errors with an apparent exit code of 0.

Minimal reproduction:

echo "BEFORE"; sleep 81; echo "AFTER"
# Expected: "BEFORE\nAFTER"
# Actual: "Tool ran without output or errors" (exit 0)

BEFORE was written to stdout immediately at t=0, but when the internal timeout fires at ~80s, even that already-flushed output is lost. The tool reports success.

Why this is dangerous

The silent success report makes it look like the command either completed with no output or never ran. The natural response is to re-run it. In our case, this caused triple-deploys (3 full docker build + push + kubectl rollout cycles) before we identified the root cause. Subprocesses spawned by the killed command (e.g., docker build) continue running in the background, so the operations partially complete despite the tool reporting nothing.

Threshold on our system

We measured ~80-81 seconds on Linux 6.17 / Claude Code 2.1.76 (via Agent SDK), vs your ~73s. Likely platform/load variance on the same mechanism.

sleep duration	timeout param	output captured?
80s	default	yes
81s	default	no - all output lost
81s	300000	no

Workaround

We built an MCP server that spawns commands via Node.js child_process.spawn directly, bypassing the Bash tool. MCP tool calls go through JSON-RPC and are not subject to the same internal timeout. Works reliably for commands of any duration.

[github-actions]

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

[github-actions]

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.