fix(tui): stop the status bar claiming '✓ daemon' when ccmuxd is dead - #178
Merged
Conversation
Found by driving the TUI in a sandbox with no daemon: no ccmuxd process, no socket, no state dir — and the status bar said '✓ daemon'. When ccmuxd is down, refresh falls back to driving tmux directly and marks the local host OK: true. That's correct for what OK means there — the DEVICE is fine, its sessions are listable, so the Devices-panel dot should stay green. But daemonOnline() reused that same flag for the status bar's daemon chip, which asks a different question: is ccmuxd answering? The Network screen's 'tmux (no daemon)' address was the only breadcrumb. This matters because the daemon is what rings the bell, sends push, and holds the sleep lock. With it dead the user gets no notifications at all — and the one indicator they'd check told them everything was fine. Split the two questions: OK = device usable, DaemonOK = ccmuxd answered. daemonOnline() reads DaemonOK. Verified live in the same sandbox: now renders '⚠ offline'. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Found by driving the TUI live. I ran ccmux in a sandboxed tmux with an isolated $HOME — no ccmuxd process, no socket, no state directory — and the status bar still read
✓ daemon.The bug
When ccmuxd is down, the refresh path falls back to driving tmux directly and marks the local host
OK: true. That is correct for whatOKmeans there: the device is fine and its sessions are listable, so the Devices-panel dot should stay green (there's an explicit comment saying so).But
daemonOnline()reused that same flag to drive the status bar's daemon chip, which asks a different question — is ccmuxd answering? The Network screen'saddress: tmux (no daemon)was the only visible hint that anything was wrong.This is worth fixing rather than tolerating: the daemon is what rings the bell, dispatches push notifications, and holds the
caffeinatesleep lock. If it dies, the user silently gets no notifications at all — and the one indicator they'd think to check showed a green check.The fix
Split the two questions on
hostStatus:OK— the device is usable (unchanged semantics; still true on the tmux fallback, dot stays green)DaemonOK— ccmuxd actually answereddaemonOnline()now readsDaemonOK. Set true where a daemon demonstrably responded (local health, configured hosts reached through their daemon, tailnet peers discovered via a ccmuxd health probe) and false on the direct-tmux fallback.Verification
⚠ offline.TestDaemonOnline_UsesLocalFlagextended with the fallback case and a "remote daemon up, local down" case. Fail-before confirmed by restoring the old predicate:daemonOnline = true, want falseon both.TestStatusBar_ReflectsRealDaemonState— new, asserts the rendered chip itself (the thing the user reads), not just the predicate.go test ./...green.🤖 Generated with Claude Code