`TERMINALS_IDLE_TIMEOUT_MINUTES=0` is documented as "disabled" but is a 30-minute reap on the kubernetes-operator backend

Version: terminals / terminals-operator 0.2.4 (unchanged on main) · backend kubernetes-operator · installed via the terminals Helm chart 0.7.0

What happens

terminals/config.py:

# Idle reaper — tear down terminals after N minutes of inactivity (0 = disabled)
idle_timeout_minutes: int = 0

but backends/kubernetes_operator.py only forwards the value when it is positive:

if idle_timeout and idle_timeout > 0:
    cr_spec["idleTimeoutMinutes"] = idle_timeout

so a CR created with the setting at 0 has no idleTimeoutMinutes, and the operator fills the gap with 30 — twice over: manifests/terminal-crd.yaml declares default: 30 / minimum: 1, and operator/handler.py does spec.get("idleTimeoutMinutes", 30). Every idle-check log line reads (timeout=30). The same applies to a policy with idle_timeout_minutes: 0.

Net effect: "disabled" is the one value that cannot be expressed on this backend, and because the default terminal has no PVC, the user's files are deleted 30 minutes after their last request. We ran with 0 for three weeks believing pods were never reaped; every model-produced file was silently vanishing.

Expected

Either of:

1. 0 means disabled all the way down — orchestrator passes idleTimeoutMinutes: 0, CRD minimum: 0, operator's idle_check returns early when the value is 0; or
2. the setting/policy field rejects 0 on this backend with a clear error and the config comment says so.

(1) matches the documented contract.

Workaround

Any large positive value (we use 1440 with a PVC-backed policy).

Start by tracing the timeout from terminals/config.py through backends/kubernetes_operator.py, manifests/terminal-crd.yaml, and operator/handler.py. Check the relevant backend and operator tests, then verify that a configured value of 0 remains disabled for both direct settings and policies, without triggering the 30-minute default.