[liususan091219]

Summary

Voice-agent kept the Gemini Live session alive even with clientConnected=false. Every ~9-min Gemini reconnect (GoAway) produced a phantom assistant turn 2-3s later — sometimes a tool call (save_meeting_note, open_url, work) that polluted notes files, opened browser tabs, or wrote phantom task files. Reproduced 100% on Studio + verified on Maddy (latest 1c350fa / bodhi ffec0cd).

Adds a 60s idle teardown:

• on handleClientDisconnected, schedule a timer
• timer calls transport.disconnect() if no client returned in time
• on handleClientConnected, cancel any pending timer
• also armed at boot so a freshly-started voice-agent with no client doesn't keep an idle session open

CLOSED is a fixed point when clientConnected=false (existing health monitor only resumes CLOSED → CONNECTING when a client is present), so no phantoms can fire until a real client reconnects.

Pre-patch evidence

12:23 turn_1 [user] hello (injected via WS)
12:23 client disconnected
12:29 GoAway → 12:29:51 turn_2 [assistant] "ack"   ← PHANTOM
12:38 GoAway → 12:38:50 turn_3 [assistant] "ack"   ← PHANTOM
... (10 phantoms / 10 reconnect cycles in 90 min)

Cross-host (Maddy): same pattern, silent-failure surface — phantom [Tool] save_meeting_note polluting notes/meeting-2026-05-04.md (17 lines, all phantom — confirmed by Susan she didn't dictate any).

Post-patch verification (Studio, latest main + this patch)

15:09:54 voice-agent restart on patched code
15:10:50 [VoiceSession] Idle 60s — closing Gemini transport (no phantoms while CLOSED)   ← BOOT teardown
15:10:50 Transport closed (state=ACTIVE code=1000), Session Ended
15:11:20 → 15:13:51 [Health] state=CLOSED client=false   ← stayed CLOSED through 4 would-be reconnect windows, zero phantoms
15:13:54 Client connected → Gemini reopens automatically (existing health-monitor recovery)
15:13:59 Client disconnected
15:14:59 [VoiceSession] Idle 60s — closing Gemini transport   ← DISCONNECT teardown fired exactly 60s after client gone

Pre-patch baseline: 90 min idle = 10 phantoms.
Post-patch: 6 min spanning boot + connect + disconnect cycle = 0 phantoms + 2 confirmed teardown events.

Test plan

• Boot voice-agent fresh, wait 60s, verify idle teardown log appears + state goes CLOSED
• Connect a client (WS text-input), verify Gemini reopens (Client connected → Gemini inactive — resetting session and reconnecting)
• Disconnect client, wait 60s, verify teardown fires again
• Verify zero `[Tool]` calls or `Turn complete` events fire while state=CLOSED
• (manual) Verify normal voice flow on a real client connection still works — voice metrics, transcripts, tool calls all behave as before

🤖 Generated with Claude Code

[sonichi]

LGTM — addresses today's lifecycle bug cleanly.

Verified architecture:

• IDLE_TEARDOWN_MS = 60_000 (60s) timer wraps handleClientDisconnected to schedule teardown, wraps handleClientConnected to cancel it.
• Initial arm at boot (line 1167) — voice-agent boots with no client; teardown fires if none connects in 60s. Closes the GoAway-without-client phantom-loop window before it can re-trigger.
• Setting timeout callback re-checks clientConnected immediately before disconnect — prevents race where a client connects between schedule and fire. ✓
• cancelIdleTeardown() clears + nulls the handle, idempotent.
• The CLOSED-as-fixed-point reasoning is correct: existing health monitor only reconnects CLOSED→CONNECTING when a client is present; without a client, the session stays closed.

Empirical context: Mini's voice-agent had 3 GoAway events clustered in 62s today (logs/voice-agent.log) — exactly the bug-shape this fixes. After this lands + bridge restarts pick up the new code, those clusters should disappear from the logs across the fleet.

Gate check (per repo norm: import strategy / defaults / bind-address):

• Import strategy: no new imports ✓
• Defaults: 60s timer is conservative; first-connect adds at most ~1-2s reconnect latency if user takes >60s post-boot to connect ✓
• Bind-address: N/A (pure timer logic) ✓

One non-blocker note: IDLE_TEARDOWN_MS is a hardcoded const. If we later observe the 60s default is too aggressive (e.g. some user pattern reconnects every ~70s), tuning means a recompile. Could expose as process.env.SUTANDO_VOICE_IDLE_TEARDOWN_MS ?? 60_000. Not in scope; defaults are sensible for the current evidence.

Approve. Recommend merging via gh pr merge --squash (no --delete-branch per repo norm).

[sonichi]

Hi @liususan091219 — Chi wants to merge this. Anything you want to address first, or ready for merge?