Allow users to control built-in status line messages (suppress, override, or prioritize custom statusLine)

Problem

Claude Code supports custom statusLine configuration via settings.json, which works well for displaying user-defined content. However, built-in status messages (model upgrade suggestions, context usage warnings, etc.) are rendered independently and cannot be suppressed, hidden, or overridden by the user's custom configuration.

This forces power users to implement fragile workarounds in their status line scripts to avoid display conflicts with built-in messages.

Related: #24543 (proposes adding dynamic data sources to the status bar — different scope but similar area)

Evidence: Real-world workarounds required

I maintain a custom statusLine script (4-line display: model name, directory, org/repo, git branch) and have had to implement multiple workarounds to coexist with built-in messages:

1. Yielding to Context warning bar

When remaining_percentage <= 20%, my script must suppress its own output entirely because the built-in "Context left" bar takes over the status line area:

# Context警告バー（remaining_percentage <= 20%）表示時はstatusline非表示
REMAINING=$(echo "$input" | jq -r '.context_window.remaining_percentage // 100')
if [ "$REMAINING" -le 20 ] 2>/dev/null; then
    exit 0  # Give up — built-in message takes priority
fi

The user's custom status line should not have to "give up" for built-in messages.

2. Unable to detect actual pane width

The hook environment does not provide reliable pane width information, making it impossible to determine whether built-in messages are consuming display space:

=== Debug log (every invocation) ===
COLUMNS=<unset>
stty size: <failed>
tput cols: 80  ← always returns full terminal width, not pane width

This means the script cannot adapt intelligently to layout changes caused by built-in messages — it can only use remaining_percentage as a proxy signal to guess when the display area is compromised.

3. CWD tracking requires multi-layer fallback

Because workspace.current_dir is not always available in the hook environment, I had to build a 3-layer fallback system across multiple scripts (statusline.sh, track-cwd.sh, inject-context.sh) just to reliably display the current directory.

Desired Behavior

Users who configure a custom statusLine should have control over all content displayed in the status line area:

1. Suppress specific built-in messages — e.g., hide model upgrade suggestions or context warnings individually
2. Override built-in messages — custom statusLine takes full priority when defined
3. Access accurate layout information — hook environment should provide actual available width, not just terminal width
4. Coexist gracefully — if both user and built-in content are desired, provide a way to compose them (e.g., user content + built-in context bar side by side)

Possible Approaches (for consideration)

• A statusLine.overrideBuiltIn: true option that gives user config full control over the status area
• A statusLine.suppress array to disable specific message categories (e.g., ["model-upgrade", "context-warning"])
• Exposing actual pane/available width in the hook JSON input (not just terminal width)
• Priority-based rendering where user statusLine config takes precedence when defined

Implementation details are best left to the team — the core ask is user sovereignty over the status line area.

Environment

• Terminal: Ghostty (TERM=xterm-ghostty)
• OS: macOS
• Claude Code: latest