fix(dashboard): blank agent-spawned terminals, inflated bridge count, Centrifugo reconnect flapping

[fkesheh]

Fixes three things the user hit in the cloud dashboard, all verified in a real browser.

1. Blank terminal for agent-spawned / re-run sessions

A session created or re-run by another agent (via the local API / fticket, not the panel) showed a blank pane with no output, on every device, while the session was clearly running.

Cause: the bridge served terminal output only when it considered the session "known", and that check (index.ts isKnownSession) counted only sessions with a PTY attached in the current process. A session alive in tmux but not attached in-process failed it, so the browser's terminal_watch was silently dropped and publish-router.ts published nothing.

Fix: isKnownSession also counts live tmux sessions (runner.hasTmuxSession), and the first watcher triggers a read-only reattach to the tmux session, reusing the existing resurrection path (no init keystroke, no agent restart), so output streams. Dropped watches are now logged. Defensively, the UI (useSessions.ts) preserves a known bridgeId across row merges so a partial update can never blank the pane.

2. "N bridges" too high (user saw 4 for one bridge)

useBridges.ts keyed the list by Centrifugo connection id, so one bridge that reconnected with a lingering old connection counted twice. It now tracks every connection per bridgeId and exposes one entry per bridge (newest connection wins); a bridge disappears only when its last connection leaves, so there is no transient "0 bridges" that would disable the + button.

3. Centrifugo reconnect flapping (the source of the duplicate connections)

The bridge subscribed to channels it only publishes to (sessions:updates, per-terminal terminal:), so Centrifugo echoed its entire output stream back; the app-level ping then queued behind that backlog and the client declared "no ping" and reconnected about once a minute, each reconnect re-publishing everything and feeding the loop.

Fixes: remove the publish-only subscriptions (publishing is permitted by allow_publish_for_client, verified against centrifugo/config.json); set maxServerPingDelay; throttle the reconnect re-sync and skip finished sessions; cache the tmux liveness probe so it stops spawning tmux has-session on every watch heartbeat; add explicit ping settings to the Solo hub config.

Verification

• 772 bridge tests, UI hook tests, tsc and build all pass.
• Isolated Docker run of this branch (nothing touched host ~/.ftown): an agent-spawned session created through the local API rendered its terminal and echoed a marker in a real browser — proving both the reattach fix and that terminal output still publishes after the subscriptions were removed. A panel-created session also round-tripped. Zero flapping keywords and zero publish permission errors over the run. Screenshot in the review notes.

Follow-ups noted, not in this PR

• events: still uses subscribe-before-publish (minor residual echo).
• ~/.ftown/bridge.json and loops.json are written from $HOME regardless of --data-dir, so a Solo instance clobbers a co-resident bridge's pointer file. This bit us during testing.
• Reattach on watch doesn't retry a transient failure until the watcher TTL sweeps; terminal-log seeding (scrollback on first attach) deferred.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
ftown	Ready	Preview	Sep 5, 2026 2:23pm UTC