[BUG] FleetView (`claude agents`) remote session entry persists on Code tab after TUI exits (zombie entries, no cleanup on relay disconnect)

Preflight Checklist

• [x] Searched existing issues; not reported.
• [x] Single bug report.
• [x] Latest Claude Code (v2.1.148 / v2.1.149 on macOS).

What's Wrong

When the FleetView / Agent View TUI (claude agents) exits — pressing ESC, terminal close, SIGTERM, SIGKILL, parent shell exit — the corresponding remote session entry on the Code tab is NOT cleaned up. It persists for tens of minutes (observed) or longer, and tapping the zombie entry on any client produces no response: no chat reply, no error, nothing.

The remote session entry is named <LocalHostName>.local-<adjective>-<noun> (e.g. niafams-macbook-pro-local-twinkling-teacup) and appears in:

• Claude Desktop → Code tab
• Claude.ai iPhone app → Code tab
• Claude.ai Android app → Code tab

While a FleetView TUI is alive, the entry works correctly — tapping it on any client opens a chat bound to FleetView's cwd, and a first interaction silently spawns a claude-named bg session in the daemon. That intended behavior is fine. The bug is purely the missing cleanup signal when the TUI process exits.

Expected Behavior

When the FleetView TUI process exits (any cause), the relay socket disconnects. The cloud side should detect this disconnect and remove the corresponding <host>.local-<adj-noun> remote session entry within a short heartbeat window (e.g. 30 seconds). Tapping a removed entry should not be possible because it should no longer be in the list.

Steps to Reproduce

1. On macOS, open a terminal and cd into any directory.
2. Run claude agents.
3. Open Claude Desktop → Code tab (or iPhone / Android Claude.ai app → Code).
4. Observe: a new <LocalHostName>.local-<adj-noun> entry appears, "Connected" (green dot on Desktop).
5. Press ESC in the FleetView TUI to close it.
6. Wait 10+ minutes.
7. Observe: the entry is still visible on every client. Status indicator does not change to "disconnected" or similar.
8. Tap the entry on iPhone or Android — chat opens but no input gets a response, no error message.

Compounding effect

Because there is no cleanup, multiple invocations of claude agents over a day (in different terminals or sequential re-runs after ESC) accumulate as multiple zombie entries. After a typical work day with frequent FleetView use, the Code tab is dominated by <host>.local-<adj-noun> entries that are not actionable. Mitigation by user discipline (one FleetView at a time) helps but does not solve the underlying cleanup gap.

Evidence

The FleetView TUI process maintains an outbound HTTPS connection to the relay:

$ lsof -p <fleetview-pid> | grep ESTABLISHED
2.1.148 76664 niafam 18u IPv6 ... TCP [...]->[2607:6bc0::10]:443 (ESTABLISHED)

When the FleetView TUI is killed (kill -TERM <pid>) the TCP connection drops on the local side — but the remote entry on Code tab remains visible for 10+ minutes. So the disconnect either is not detected server-side, or detection does not trigger entry removal.

claude agents --json does NOT list the FleetView TUI host process (only kind: "background" | "interactive" sessions), so there is no way for the user to enumerate the leaked remote entries from the CLI.

Workaround

• Use claude agents --json for read-only inspection — print + exit, no remote entry registered.
• Run claude agents (TUI) once and keep it alive in a dedicated tmux pane to minimize re-invocation.
• No way today to manually delete zombie entries — no API or UI for it.

Environment

• macOS 15 (Sequoia), Apple Silicon (M3 Max)
• Claude Code v2.1.148 and v2.1.149
• Terminal: iTerm2 + tmux
• Claude Desktop latest; Claude.ai iPhone app latest

Related Issues

• #60975 — FleetView: allow specifying a starting directory (cwd) when spawning a new agent. Different symptom (cwd default).
• #61546 — duplicate of #60975.