clikae v0.22.0 — the board knows what is running

The board knows what is running

Type clikae and the top of the page now lists the sessions alive on this
machine — and Enter attaches to one, rather than starting anything.

  ▸ Live
    ● work    claude   "auth redirect — next: retry the callback test"
    ● x       codex    "Transcreate the escape guides to 7 locales"

  ▸ Tanks
    …

This came from someone ssh'ing into their Mac, running clikae, and finding the
session they had left running nowhere on the page. The board could say which
accounts they had and what they did yesterday. What is alive was a category
tmux created, and the board never grew it.

v0.21.0 made that sharper rather than better: keying a session on the arguments
it was started with is correct, but it means the Resume row opens a second
conversation. Without a Live section there was no way back into the first one
except remembering the tank's name.

The third column is the session's title, not a status word. claude/x does
not tell you which piece of work that is — and "I need to know the name I gave
it" was the whole reason to build the section this way.

Selecting a row adds one line beneath it. For a tank that has hit its limit, that
line is the vendor's own sentence, verbatim — and clikae's promise on the line
after, only when a waiter is genuinely attached:

  ❯ x       claude   "Transcreate the escape guides"
        You've hit your session limit · resets 3:50am (Asia/Tokyo)
        -> resuming in 13h38m

resets is their fact. resumes is ours.

Only this machine, and it says so

tmux is local, so running clikae on a tablet lists the tablet's sessions. That
is stated in the docs rather than papered over: it is the truth about where a
session lives, and seeing it makes the mental model right. To reach a session on
another machine, log in first, then run clikae there — ssh yourmac 'clikae'
hands the command a pipe for output, so clikae correctly takes its no-tmux path
and the section is absent.

No tmux installed means no section at all, not an empty heading.

The tank is resolved against the disk, not parsed

ck-claude-my-tank-123 is either tank my-tank with an argv digest, or tank
my-tank-123. Both are legal names, so the parse is genuinely ambiguous — and
guessing would be the kind of decision that looks right until someone names a
tank with a number in it.

Asking the filesystem which reading exists settles it, and buys something else
for free: a session whose tank has since been removed drops off the board instead
of drawing a row that cannot be opened.

Two notes from the tests, because both were nearly the wrong conclusion

The obvious fixture proved nothing. For "somebody else's tmux session is none
of clikae's business", a session called notclikae-1 is rejected by the
tank-exists check whether or not the ck- gate is there — so both guards could
have been deleted and the suite stayed green. The specimen is adversarial now,
one character from being ours. That turned up something worth writing down: the
two ck- gates are redundant on purpose — widening either alone leaves the
suite green, widening both turns exactly that test red. Recorded in the file,
because "nothing fails when I delete it" is the usual reason a redundant guard
gets deleted.

Adding the new test file turned two older tmux tests red, while they passed
3/3 on their own. A controlled run with the file moved aside confirmed the
trigger was the new file — and the cause was theirs: fixed-second waits. One was
waiting for "nothing in tmux is attached", which is never true on a machine
with a session open, so it burned its whole timeout every run and, under a loaded
suite, outlived the stub engine it was measuring. The session died, the next
attach made a new one, and an assertion about roaming failed for a reason that
had nothing to do with roaming. Both wait on real conditions now.

---

brew upgrade clikae · CHANGELOG