Bash tool has a hard 10-minute (600s) timeout that cannot be overridden

Resolved 💬 2 comments Opened Feb 15, 2026 by jtokash Closed Mar 15, 2026

Problem

The Bash tool has a hard maximum timeout of 600,000ms (10 minutes). This cannot be increased or disabled. The tool definition states:

You can specify an optional timeout in milliseconds (up to 600000ms / 10 minutes). If not specified, commands will timeout after 120000ms (2 minutes).

Why this is a problem

Many legitimate development workflows require long-running commands:

  • AI subagent invocations (e.g., codex exec with complex tasks) routinely take 5-20 minutes
  • Large test suites can exceed 10 minutes
  • Build processes (compiling iOS apps, large Rust/C++ projects) often take 15-30+ minutes
  • Database migrations on large datasets
  • Docker builds with many layers
  • ML training runs or data processing scripts launched from the CLI

When a command hits the 600s ceiling, it is killed mid-execution, potentially leaving state corrupted (partial merges, incomplete builds, half-written files).

Expected behavior

There should be no hard maximum timeout, or at minimum it should be configurable (e.g., via CLAUDE_BASH_TIMEOUT env var or a setting in ~/.claude/settings.json). Users should be able to set timeout: 0 or timeout: null to mean "no timeout."

The 2-minute default is reasonable as a default, but the 10-minute ceiling is an arbitrary restriction that blocks real-world workflows.

Workaround

Currently the only workaround is run_in_background: true, but this changes the execution model (non-blocking) and requires polling for results, which is clunky for sequential workflows.

Environment

  • Claude Code v2.1.42
  • macOS (Darwin 25.2.0)

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗