Statusline: hardcoded 72-column cap has no escape hatch, so wide terminals go unused (+ optional wide layout)

[xmasyx]

Summary

LIFEOS_StatusLine.sh caps its render width at a hardcoded 72 columns with no way to opt out. On a wide terminal the dashboard occupies the leftmost 72 columns and leaves everything to the right of them empty, no matter how much room is actually available.

I understand the cap is intentional — the comment says so. This is a request for an escape hatch, not a claim that the default is wrong.

Where

LifeOS/install/LIFEOS/LIFEOS_StatusLine.sh, lines 504–507 (read from main via the GitHub contents API today, so the line numbers are current):

# Content width: cap at 72 so wide terminals don't stretch, but narrow ones fit
content_width=$term_width
[ "$content_width" -gt 72 ] && content_width=72
[ "$content_width" -lt 10 ] && content_width=10

content_width feeds SEP_SOLID / SEP_DASHED / SEP_DOT, the context-bar width, and every wrap calculation, so the whole dashboard inherits the 72.

Why it matters more now than it used to

Claude Code's fullscreen renderer (/tui fullscreen) pins the statusline to the bottom of the screen instead of letting it scroll away with the conversation. Once the dashboard is permanently on screen, its height is a standing cost, and height is exactly what the width cap forces: on a 150-column terminal the current layout renders around 15 stacked rows while using less than half the available width. Anything that could sit side by side is stacked instead.

Suggested fix — 1: make the cap configurable

Three lines, default unchanged, so nobody's current render moves:

# Content width: cap at MAX_WIDTH (default 72) so wide terminals don't stretch,
# but narrow ones fit. Set LIFEOS_STATUSLINE_MAX_WIDTH=0 to use the full width.
: "${LIFEOS_STATUSLINE_MAX_WIDTH:=72}"
content_width=$term_width
if [ "$LIFEOS_STATUSLINE_MAX_WIDTH" -gt 0 ] 2>/dev/null; then
    [ "$content_width" -gt "$LIFEOS_STATUSLINE_MAX_WIDTH" ] && content_width="$LIFEOS_STATUSLINE_MAX_WIDTH"
fi
[ "$content_width" -lt 10 ] && content_width=10

Suggested fix — 2: an optional wide/compact layout

With the cap lifted, the natural follow-up is a layout that actually spends the width. Pairing blocks left/right collapses the normal-mode render from roughly 15 rows to 4:

LIFEOS 7.1.1 │ CC 2.1.220 │ ALGO 8.4.0 │ <MODEL>                    <SESSION LABEL>
ACTIVE: <rungs> │ <cross-vendor engines>              ⚡ LOW MEDIUM HIGH XHIGH MAX
                                        🧠 OK · REVIEWED 10M AGO · NEXT IN 5 TURNS
CONTEXT: 12% │ STARTUP LOAD: 2.8% ≈ 28.6K TOK      📊 5HR 14% ↻2030 WK 38% ↻SUN@23

Two things that are easy to get wrong there, both of which cost me a debugging pass:

1. Width has to be reported, not re-derived. detect_terminal_width() has five tiers, and tiers 4–5 do not write $_width_cache. Anything downstream that re-detects the width can land on a different number than the one the separators were drawn with, and the right-hand column then sits a few columns off. Whatever composes the columns should be handed content_width directly.
2. Emoji are two display columns wide but one character. ${#var} counts characters, so right-aligning a segment that starts with ⚡, 🧠 or 📊 using ${#} shifts it by one column per emoji.

A third, separate observation: hosts may not give the statusline the terminal's full width. Under Claude Code's fullscreen renderer, asking for the last column got the end of my right-hand column replaced with …; reserving a few columns fixed it. If a wide layout lands upstream, a small configurable right margin is probably worth having.

I'm happy to open a PR for fix 1 if that's useful — it's the self-contained half.

Repro

1. Open a terminal at 150 columns.
2. Start a session with the LifeOS statusline configured.
3. The dashboard renders inside the first 72 columns; the remaining ~78 are blank.

[xmasyx]

Adding the motivation for suggested fix 2, which I under-stated above. The compact layout isn't cosmetics — it's a response to a change in how Claude Code renders.

Why the height matters now

Claude Code's fullscreen renderer (/tui fullscreen) pins the statusline to the bottom of the screen. It no longer scrolls away with the conversation, the way it did under the classic main-screen renderer.

That flips what the dashboard's height costs. Before, a tall statusline was a one-off cost per render that scrolled out of view a moment later. Now it is permanent screen real estate, subtracted from the conversation for the whole session. On a laptop — call it 35 to 45 rows of usable height — the current normal-mode render at roughly 15 rows is a third of the window, always. On smaller external screens and on a split pane it is worse.

And the width cap makes it worse than it needs to be: those 15 rows are stacked inside 72 columns while the rest of the terminal sits empty, so the dashboard is paying in the scarce dimension (height) to save the abundant one (width).

The shape of the fix

An opt-in setting, not a redesign. Something like:

: "${LIFEOS_STATUSLINE_LAYOUT:=classic}"   # classic | compact

classic keeps today's render byte-for-byte, so nobody's dashboard moves. compact pairs blocks left/right and collapses normal mode from ~15 rows to 4:

LIFEOS 7.1.1 │ CC 2.1.220 │ ALGO 8.4.0 │ <MODEL>                        <SESSION LABEL>
ACTIVE: <rungs> │ <cross-vendor engines>                  ⚡ LOW MEDIUM HIGH XHIGH MAX ULTRA
                                          🧠 OK · REVIEWED 11M AGO · NEXT IN 4 TURNS · 60% FULL
CONTEXT: 12% │ STARTUP LOAD: 2.8% ≈ 28.6K TOK        📊 5HR 16% ↻2030 WK 38% ↻SUN@2300 FB 0% SUB

The two savings that make the row count work, both worth having on their own:

• The context bar is a one-number chart. Rendering it only above an alarm threshold (say 70%) and otherwise printing just CONTEXT: 12% inline frees a row plus its separator.
• The per-file startup-load breakdown is what you need while you are trimming context, not on every tick. Showing it only when a single file or the total crosses a threshold folds four rows into one, and it reappears by itself when it matters.

Notes from having built it

I've been running this locally for a few hours. Beyond the two traps in the issue body (width must be reported rather than re-derived; emoji are two display columns but one character), one more:

• Don't assume the host gives you the terminal's full width. Under the fullscreen renderer the statusline is drawn inside a frame, and asking for the last column got the tail of my right-hand column replaced with …. Reserving a few columns fixed it, so a small configurable right margin belongs with a wide layout.

I offered a PR for fix 1 above; the offer extends to this one too if the direction is welcome. Happy to follow whatever shape you prefer for the setting — env var, config key, or a width threshold that switches automatically.

[danielmiessler]

Good catch, @xmasyx — the statusline 72-column cap had no escape hatch. Fixed in source (added LIFEOS_STATUSLINE_MAX_WIDTH), ships next release. Closing since the public repo is generated from that source.