Symptom
After a laptop sleep, VS Code terminal tabs show [Codev: Connection lost. unable to reconnect after 6 attempts. Click here to reconnect] and stay dead until manually reconnected — while Tower is perfectly healthy.
Field specimen 2026-09-14 ~9:41 PM: tab died with the 6/6 banner; diagnosis showed Tower up continuously for 5 days (uptime 433,612s at check, healthy, 39 terminals). The disconnect was purely client-side: the machine slept, and the extension's reconnect attempts fired against a suspended network stack — each fails instantly, so the whole 6×30s budget burns before full wake. The agent itself (detached shellper) was unaffected throughout; only the view died.
Defect
The reconnect policy is a fixed, exhaustible budget with no awareness of why attempts fail. Sleep/wake — the single most common disconnect cause on a laptop — reliably consumes it, converting a transient OS event into a permanent-looking failure banner across every open terminal tab.
Fix shape (lane's judgment)
- Reset the retry budget on wake signals: window focus,
online network event, or visibility change — any of these arriving should re-arm a parked client.
- And/or replace the hard 6-attempt death with capped exponential backoff (e.g. 30s → 5m cap) that never fully terminates while the tab is visible; the "Click here" affordance stays as the immediate manual path.
- Cheap discriminator worth adding: on final failure, probe
/health once and word the banner honestly — "Tower unreachable" vs "reconnect failed (Tower is up — click to retry)". Tonight's specimen shows the second case wearing the first case's message.
Related: #1052 (window-reactivation terminal corruption — same wake window, different layer); the #1047 resume machinery already makes reattach cheap, so aggressive auto-reconnect is safe.
Symptom
After a laptop sleep, VS Code terminal tabs show
[Codev: Connection lost. unable to reconnect after 6 attempts. Click here to reconnect]and stay dead until manually reconnected — while Tower is perfectly healthy.Field specimen 2026-09-14 ~9:41 PM: tab died with the 6/6 banner; diagnosis showed Tower up continuously for 5 days (uptime 433,612s at check, healthy, 39 terminals). The disconnect was purely client-side: the machine slept, and the extension's reconnect attempts fired against a suspended network stack — each fails instantly, so the whole 6×30s budget burns before full wake. The agent itself (detached shellper) was unaffected throughout; only the view died.
Defect
The reconnect policy is a fixed, exhaustible budget with no awareness of why attempts fail. Sleep/wake — the single most common disconnect cause on a laptop — reliably consumes it, converting a transient OS event into a permanent-looking failure banner across every open terminal tab.
Fix shape (lane's judgment)
onlinenetwork event, or visibility change — any of these arriving should re-arm a parked client./healthonce and word the banner honestly — "Tower unreachable" vs "reconnect failed (Tower is up — click to retry)". Tonight's specimen shows the second case wearing the first case's message.Related: #1052 (window-reactivation terminal corruption — same wake window, different layer); the #1047 resume machinery already makes reattach cheap, so aggressive auto-reconnect is safe.