Motivation
On a phone over mosh the companion card eats a fifth of the visible screen. Measured from a live iPhone mosh session into the Mac mini:
PTY size = 30 rows x 62 cols (desktop is typically 50-60 rows)
The card is 6 lines. On a 30-row terminal that is 20% of everything visible.
Why size, not transport
Both signals are available and verified present in that session:
MOSH_SERVER_NETWORK_TMOUT, MOSH_SERVER_SIGNAL_TMOUT (mosh)
SSH_CLIENT, SSH_CONNECTION (ssh)
But keying on transport is wrong: mosh from a laptop with a large terminal would collapse unnecessarily, and a small local split would stay full-size. Terminal size is the honest cause. Transport vars are a reasonable secondary hint only if a host ever hides the PTY.
Proposal
The renderer already drops the bubble as a unit when it cannot fit horizontally (canFrame). This is the same idea on the vertical axis: a line budget derived from rows.
full (>= 40 rows) current card, 6 lines
compact (20-39 rows) 3 lines - sprite trimmed to core rows, name inline, bubble dropped
minimal (< 20 rows, or very narrow) 1 line - `(@ @) Cobalt **` plus reaction if it fits
Rows are already obtainable on the existing detection path — stty size returns both dimensions and the script currently discards the row count.
Config: a statuslineDensity setting with auto (default) plus explicit full/compact/minimal overrides, so a user can pin it.
Not viable: click to expand
Worth recording so it is not re-proposed. A Claude Code statusline is a command that prints a string; the host renders it and there is no input channel back. No mouse events, no hit regions, no toggle state. Any expand/collapse must be automatic or driven by a /buddy command, not by tapping the pet.
Verification
Extend the existing golden width matrix (scripts/ci/check-statusline.sh) with a rows dimension, asserting the emitted line count stays within budget at representative sizes, and that the companion name remains visible at every density.
🤖 This content was generated with AI assistance using Claude Opus 5.
Motivation
On a phone over mosh the companion card eats a fifth of the visible screen. Measured from a live iPhone mosh session into the Mac mini:
The card is 6 lines. On a 30-row terminal that is 20% of everything visible.
Why size, not transport
Both signals are available and verified present in that session:
But keying on transport is wrong: mosh from a laptop with a large terminal would collapse unnecessarily, and a small local split would stay full-size. Terminal size is the honest cause. Transport vars are a reasonable secondary hint only if a host ever hides the PTY.
Proposal
The renderer already drops the bubble as a unit when it cannot fit horizontally (
canFrame). This is the same idea on the vertical axis: a line budget derived from rows.Rows are already obtainable on the existing detection path —
stty sizereturns both dimensions and the script currently discards the row count.Config: a
statuslineDensitysetting withauto(default) plus explicitfull/compact/minimaloverrides, so a user can pin it.Not viable: click to expand
Worth recording so it is not re-proposed. A Claude Code statusline is a command that prints a string; the host renders it and there is no input channel back. No mouse events, no hit regions, no toggle state. Any expand/collapse must be automatic or driven by a
/buddycommand, not by tapping the pet.Verification
Extend the existing golden width matrix (
scripts/ci/check-statusline.sh) with a rows dimension, asserting the emitted line count stays within budget at representative sizes, and that the companion name remains visible at every density.🤖 This content was generated with AI assistance using Claude Opus 5.