[FEATURE] Support standalone buddy display and composable status lines

[malammar]

Feature Request: Support standalone buddy display and composable status lines

Problem

Currently, claude-buddy takes over the entire statusLine configuration in Claude Code settings. This conflicts with users who already have custom status lines (e.g., showing git branch, emojis for context usage, Node.js version, etc.).

The buddy's multi-line ASCII art display also doesn't fit well in a single-line status bar format, making it difficult to show both the buddy and traditional status information simultaneously.

Use Cases

1. Standalone buddy viewer: Users want to run the buddy display in a separate terminal/tmux pane while keeping their existing status line
2. Composable status lines: Users want to show compact status info (git, context, model) alongside a simplified buddy indicator (e.g., just eyes or name)
3. Side-by-side display: Users want the full animated buddy experience without sacrificing their workflow information

Current Workaround

Created a wrapper script that continuously runs statusline/buddy-status.sh in a loop:

#!/bin/bash
clear
tput civis
trap 'tput cnorm; exit' INT TERM EXIT

while true; do
    tput cup 0 0
    echo '{}' | /home/mustafa/Downloads/claude-buddy/statusline/buddy-status.sh
    sleep 1
done

Users can run this in a tmux pane alongside Claude Code.

Proposed Solutions

Option 1: Built-in standalone mode

Add a --watch or --standalone flag to the buddy CLI that runs continuously:

claude-buddy show --watch
# or
buddy --standalone

Option 2: Compact status line mode

Provide a single-line buddy display option that shows just:

• Eyes + name (e.g., ◉◉ Ember)
• Current reaction as tooltip/inline text

This could coexist with other status line content.

Option 3: Composable status line helper

Provide a function/script that returns just the buddy rendering without taking over the entire statusLine, allowing users to combine it with their own scripts:

# In user's custom statusline script
my_status_info="$(show_git_and_context)"
buddy_status="$(claude-buddy status --inline)"
echo "$my_status_info  $buddy_status"

Option 4: Document the pattern

Simply document the workaround approach and provide example scripts for:

• Running buddy in a tmux pane
• Integrating buddy into existing status line scripts
• Creating aliases for easy launching

Benefits

• Users can keep their existing status line configurations
• Better support for tmux/split-pane workflows
• More flexible integration options
• Buddy remains visible even when status line space is limited

Related

This came up while trying to preserve a custom status line showing:

• 🌑 Moon phases (context window usage)
• Git branch and dirty state
• Node.js version
• Model name

All of which are useful workflow information that shouldn't be replaced by the buddy display.

[lucasbrandao4770]

@malammar Hi! I ran into this exact problem — buddy replaced my custom status line (git branch, model, context window bar) on install. I ended up building a working solution that addresses Option 3 (composable status lines) and wanted to share the approach.

What I built

The core idea: buddy accepts user content via a USER_INFO env var and embeds it in its own padding area. The buddy script already pads every line with ~90+ spaces for right-alignment. Instead of blank padding on line 1, it renders the user's info there — same total width, so the ASCII art alignment is preserved.

A thin wrapper script captures the user's status line output and passes it:

#!/bin/bash
SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"

# Capture Claude Code's JSON payload from stdin
INPUT=$(cat)

# Run the user's custom status line script and capture its output
if [ -x "$SCRIPT_DIR/statusline.sh" ]; then
    export USER_INFO=$(printf '%s\n' "$INPUT" | "$SCRIPT_DIR/statusline.sh")
fi

# Buddy reads USER_INFO and embeds it in its padding area
# NOTE: adjust this path to your claude-buddy install location
"$HOME/.claude/claude-buddy/statusline/buddy-status.sh"

The changes to buddy-status.sh are ~25 lines, inserted after the SPACER is calculated:

EMBED_INFO=0
USER_INFO="${USER_INFO:-}"
if [ -n "$USER_INFO" ]; then
    # Strip ANSI SGR codes to measure visible width
    INFO_VIS=$(printf '%s' "$USER_INFO" | sed $'s/\033\[[0-9;]*m//g')
    INFO_W=${#INFO_VIS}
    if [ "$INFO_W" -le "$PAD" ]; then
        # Fits: embed user info + remaining padding (same total width as SPACER)
        EMBED_INFO=1
        INFO_PAD=$(( PAD - INFO_W ))
        INFO_SPACER=$(printf '%s%s%*s' "$B" "$USER_INFO" "$INFO_PAD" "")
    else
        # Doesn't fit: print info on its own line, buddy goes below left-aligned
        printf '%s%s\n' "$B" "$USER_INFO"
        PAD=1
        SPACER=$(printf '%s%*s' "$B" "$PAD" "")
    fi
fi

Then in the output loop, line 1 uses INFO_SPACER while all other lines use the normal SPACER.

Result

The user's info renders inline on the same row as the buddy art. Full ANSI colors are preserved:

When the terminal is too narrow (info wider than available padding), it falls back to stacked layout — info above, buddy left-aligned below. This handles window resizing and font size changes gracefully.

NOTE: Having the fallback logic change the PAD to 1 (buddy renders on the left) is a personal choice, as I feel like it is prettier in the left side in that case, and can be removed so the buddy renders on the right (might be weird if the user's statusline doesnt fully cover the line, leaving empty space on top of the buddy sometimes) or could be made into a simple configuration option so the user can choose to render it on left or right like I mention below (would need some defensive logic for some edge cases tho).

Extending to multi-line status bars

The same approach scales to multi-line user content naturally. The padding math is identical per line — it's the same check (visible_width <= PAD) applied in a loop instead of just on line 1. User lines get embedded into the corresponding buddy art lines:

• 2 user lines, 5 buddy lines → lines 1-2 get user info, lines 3-5 get normal padding
• 5 user lines, 5 buddy lines → every line has embedded info
• 7 user lines, 5 buddy lines → lines 1-5 embedded, lines 6-7 printed above the buddy block

The fallback behavior could also be configurable — when content doesn't fit side-by-side, buddy could either left-align (compact) or stay right-aligned on the next row, controlled by a single env var like BUDDY_FALLBACK=left|right.

What this doesn't cover

• Standalone tmux mode (Option 1) — different use case, the existing workaround in the issue description works well for that
• Compact single-line mode (Option 2) — would need a separate rendering path
• The install-time overwrite — install-buddy still forcefully replaces statusLine in settings.json, which is the root friction. Ideally the installer should detect existing configs and offer to merge rather than overwrite.

Notes

• Tested on macOS only (Darwin 25.3.0, 150-column terminal)
• The macOS terminal width detection fix in fix(statusline): add macOS terminal width detection #70 is a prerequisite — without it, buddy falls back to COLS=125 regardless of actual terminal width
• USER_INFO is backward compatible — when unset, buddy renders exactly as before
• Common ANSI SGR color codes in user content are handled correctly (stripped for width measurement, passed through for rendering)

Happy to open a PR if this direction is interesting. Also open to alternative approaches — this solves the "buddy as host" composition model, but a complementary --render=raw flag for "buddy as component" (where the user's script calls buddy and places the output) could cover more advanced use cases.

[malammar]

Fantastic solution @lucasbrandao4770! I tested your code on my instance and it worked perfectly.