[BUG] Bash tool `timeout` parameter silently clamps values above the 600000ms max instead of erroring

Status Open
Reported on v2.1.220
Maintainer reply None cached
Activity 1 comment · opened Aug 4, 2026

Description

The Bash tool's timeout parameter is documented as "default 120000, max 600000" (ms). Passing a value above the max returns no validation error — the value is silently clamped to 600000. The caller's working model then diverges from reality: the agent believes it granted e.g. 16 minutes, but the command is killed at exactly 10:00.

Repro (v2.1.219 Windows desktop / local agent mode; npm CLI 2.1.220 same behavior)

  1. Invoke the Bash tool with timeout: 960000 and a long-running command.
  2. No error at call time.
  3. The command is killed at exactly 10m 0s ("Command timed out after 10m 0s").

Why it matters — a concrete failure chain

The codex-review plugin's command template runs timeout 600 codex exec … in the foreground. The inner timeout 600 can never fire because the outer tool cap is also 600s — any round approaching 600s is killed by the harness first, the output file is left empty, and the entire round's tokens are wasted. Measured rounds on a ~350KB payload: 380–453s, so normal variance regularly crosses the cap. The silent clamp is what let the wrong mental model survive: the agent had explicitly requested a larger timeout and received no signal that it was reduced.

Expected

Either reject out-of-range values with a validation error (preferred), or return the effective timeout in the tool result so the caller knows the value was clamped.

Environment: Claude Code desktop 2.1.219 / npm 2.1.220, Windows 11.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗