[FEATURE] Interactive /statusline picker: choose, reorder and live-preview built-in status line components

Preflight Checklist

• [x] I have searched existing requests and this feature has not been requested.
• [x] This is a single feature request (not multiple features).

Problem Statement

statusLine runs an external command on every render and pipes it a JSON payload. That is strictly more powerful than a fixed set of built-in components, and strictly less accessible: to get any status line at all, a user has to write, debug and maintain a render script, and nothing in the product says what the payload contains.

The built-in /statusline does not close that gap. It spends a conversational turn asking the model to spawn the statusline-setup agent, which derives a line from the shell prompt and edits settings.json. There is no way to say "show model, context and the 5-hour limit, in that order" without code, and no way to see the result before committing to it.

The issue tracker shows the cost. #82885 asks for one fixed preset because every user who wants that line "re-implements the same script", and a long tail of open requests asks for single fields to be exposed so that those scripts can show them. Each of those users is maintaining a renderer for values Claude Code already computes on every render.

Proposed Solution

Make /statusline an in-TUI picker over built-in components, the way Codex does it: a checklist with a live preview line.

• A list of built-in components: model with effort, context tokens used over window, 5-hour and 7-day limits, session id, cost, version with install skew, directory, branch.
• space toggles, arrows reorder, the preview line updates per keystroke, Enter saves, Esc cancels.
• The saved value is an ordered list of component ids. Membership is the selection and order is the render order. An unknown id is skipped, a duplicate is dropped, an empty list is a valid empty bar.
• The change lands on the next render. No restart, no interruption to the running session.
• statusLine.command stays exactly as it is for anyone who wants full control.

I built a working prototype to check that this is feasible, and to find the edge cases before proposing it:

https://github.com/konsta95/ClaudeCodeStatusline (MIT)

What it demonstrates:

• The data is already there. All eleven components render from the existing payload plus bounded file reads, with no transcript parsing and no subprocess. The one value the payload lacks is the git branch, which the renderer reads straight from .git/HEAD. The renderer is one 537-line file with no dependencies.
• A self-describing registry makes the picker small. The renderer answers --segments and --schemes; the picker holds no copy of either list, and previews by invoking the real renderer against a candidate config, so a preview cannot drift from what saving produces.
• The config contract above is enough. It is seven rules, modelled on Codex status_line_setup.rs, and the README states them.
• The edge cases are real and already paid for. Entering raw mode with the default flush silently drops a key typed during launch. CSI sequences leak phantom keypresses unless consumed through the final byte. A lone Esc needs a settle window. A hung or garbage renderer must degrade to a notice, not a crash. SIGTERM, SIGHUP and a launch-window Ctrl-C must all put the terminal back. Each of these was observed failing before it was fixed, and the repository keeps the pty lab that shows it.

What the prototype cannot do is the reason this is a feature request. A full-screen picker needs a controlling terminal, so it cannot live inside the Claude Code TUI. The prototype gets as close as an outside tool can: AskUserQuestion popups that offer candidate bars rendered through the real renderer, and a tmux pane for free-form reordering. A built-in picker needs neither compromise, and it would be smaller than the prototype, because it would not need a separate renderer process, a config file of its own, or an exit-code carrier to get an answer out of a pane.

A built-in renderer would also be cheaper at run time. The prototype costs about 125 ms per refresh on my machine, nearly all of it Node startup. Built-in components cost no process spawn at all.

Alternative Solutions

• The status quo: write and maintain a render script. It works, and it is the barrier this request is about.
• The current /statusline agent flow: it produces one line derived from the shell prompt. It offers no component selection, no ordering and no preview.
• A fixed preset, as in #82885: it helps the users who want exactly that line. A picker over components subsumes presets, since a preset is a saved selection.
• The prototype itself: usable today as a workaround, with the two compromises named above.

Priority

Medium - Would be very helpful

Feature Category

Interactive mode (TUI)

Additional Context

Measured against Claude Code 2.1.247 for the payload schema and 2.1.274 for current behaviour, on Linux. The interactive picker also has a native Windows console driver, which has not yet been driven on a physical Windows console. The README says so.