Skip to content

fix(tui): stop the status bar claiming '✓ daemon' when ccmuxd is dead - #178

Merged
skzv merged 3 commits into
mainfrom
claude/fix-daemon-chip-lie
Aug 4, 2026
Merged

fix(tui): stop the status bar claiming '✓ daemon' when ccmuxd is dead#178
skzv merged 3 commits into
mainfrom
claude/fix-daemon-chip-lie

Conversation

@skzv

@skzv skzv commented Aug 4, 2026

Copy link
Copy Markdown
Owner

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 what OK means 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's address: 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 caffeinate sleep 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 answered

daemonOnline() now reads DaemonOK. 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

  • Live, same sandbox: now renders ⚠ offline.
  • TestDaemonOnline_UsesLocalFlag extended with the fallback case and a "remote daemon up, local down" case. Fail-before confirmed by restoring the old predicate: daemonOnline = true, want false on both.
  • TestStatusBar_ReflectsRealDaemonState — new, asserts the rendered chip itself (the thing the user reads), not just the predicate.
  • Full go test ./... green.

🤖 Generated with Claude Code

skzv and others added 3 commits August 4, 2026 11:37
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>
@skzv
skzv merged commit 220ed0d into main Aug 4, 2026
6 checks passed
@skzv
skzv deleted the claude/fix-daemon-chip-lie branch August 4, 2026 18:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant