[BUG] Bash tool `timeout` parameter silently clamps values above the 600000ms max instead of erroring
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)
- Invoke the Bash tool with
timeout: 960000and a long-running command. - No error at call time.
- 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.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗