pub const IDLE_TIMEOUT_FLOOR_SECS: u64 = 120;Expand description
The floor an idle timeout can never be configured below (D-02/D-04, 31-02).
Raised 30s -> 120s on 2026-08-03, and the reasoning that set 30s was wrong — read this before touching it again.
The original ≥30s floor cited “~4.2x margin” against an every-line signal
whose observed max was 7.09s. Both numbers were real; the inference was not.
Phase 30d measured backgrounded 10s/22s sleeps, where the agent is never
sitting inside a long foreground tool call. Under one, the CLI emits
tool_progress keepalives on a fixed 30.00s interval, so a healthy,
hard-working child produces a 30.00s gap between stream lines — dead level
with a 30s timeout, and on the wrong side of it, since the timer starts when
the previous line is processed while the keepalive arrives 30s after it
was sent, plus pipe latency.
Measured 2026-08-03, CLI 2.1.220, five workload-controlled trials across two
unrelated workload types (each verified to have actually run — elapsed >=
the workload duration, no tool_use_error), plus a negative control:
| workload | gaps > 5s |
|---|---|
| 90s busy loop x3 | ~26.4, 30.00, ~30.0 |
cargo test --workspace x2 | ~26.4, 30.00, ~16 |
| control (no long call) | max 2.2 |
Variance across all five: ±0.02s. cargo test --workspace is not a contrived
case — it sits inside DevFlow’s own post-merge gate, so the old floor would
have killed healthy Code stages on the common path.
120s is 4x the measured cadence: it survives three consecutive missed keepalives. That headroom is the point — the hazard is not a slightly larger gap but a dropped keepalive, which doubles the interval outright. 90s (two missed) is the lowest defensible value; do not go below it.
Do NOT lower it, and note that no configuration can. Phase 30d measured a 12-second bound killing a LIVE, HEALTHY run in 2 of 7 trials.
What the five trials do not establish: one machine, idle, one CLI version, two workload types. They show the 30.00s cadence is real and reproducible; they do not prove the interval is fixed across load, hardware, or CLI versions. That is precisely why this floor sits well above the observed maximum rather than near it.
Because the default IS the floor, the value can only ever be raised.