BASH_DEFAULT_TIMEOUT_MS and BASH_MAX_TIMEOUT_MS environment variables are non-functional

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:

``bash
export BASH_DEFAULT_TIMEOUT_MS=300000
export BASH_MAX_TIMEOUT_MS=600000
``

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

``bash
# With timeout: 600000 parameter
sleep 120
``

1. 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

1. 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