Problem
The context box rendered by wheeler-statusline.js has no configuration surface. The token count, the percentage, the bar, the element order, and the severity color thresholds are all literals inside the render path. A user who wants any layout other than the shipped one has to hand edit the installed hook at ~/.claude/hooks/wheeler-statusline.js, and the installer overwrites that file on every install and update (wheeler/installer.py:372-380 unlinks the destination and recopies unconditionally), so the customization is silently lost.
Notably, the statusline consumes context_window from the statusline stdin payload but renders only a bar and a percentage. The raw token count is available in that payload and is never shown, which is the single most requested number.
Steps to reproduce
- Install Wheeler so that
~/.claude/settings.json has "statusLine": {"type": "command", "command": "node \"~/.claude/hooks/wheeler-statusline.js\""}.
- Decide you want the context segment to read
62.7k (7%) ██░░░░░░░░ instead of the shipped ██░░░░░░░░ 7%.
- Look for any Wheeler config key, env var, or
/wh: command that changes it. There is none.
- Hand edit
~/.claude/hooks/wheeler-statusline.js.
- Run a Wheeler install or update. The edit is gone.
Error output
There is no error. The failure is silent on both ends: no config surface to discover, and no warning when the hand edit is discarded.
The shipped render path, with every format decision inlined:
const AUTO_COMPACT_BUFFER_PCT = 16.5;
if (used < 50) {
ctx = ` \x1b[32m${bar} ${used}%\x1b[0m`;
} else if (used < 65) {
ctx = ` \x1b[33m${bar} ${used}%\x1b[0m`;
} else if (used < 80) {
ctx = ` \x1b[38;5;208m${bar} ${used}%\x1b[0m`;
} else {
ctx = ` \x1b[5;31m${bar} ${used}%\x1b[0m`;
}
...
process.stdout.write(
`${wheelerUpdate}${gsdUpdate}\x1b[2m${model}\x1b[0m │ \x1b[2m${dirname}\x1b[0m${ctx}`
);
Fields available in the statusline stdin payload but unused by the renderer:
"context_window": {
"total_input_tokens": 52846,
"context_window_size": 1000000,
"current_usage": {
"input_tokens": 2,
"output_tokens": 443,
"cache_creation_input_tokens": 770,
"cache_read_input_tokens": 52074
},
"used_percentage": 5,
"remaining_percentage": 95
}
Expected behavior
A user can change the context box presentation through Wheeler, without editing an installed file, and the choice survives install and update. At minimum the following should be controllable: whether the raw token count is shown, whether the percentage is shown, whether the bar is shown, the order of those elements, and the severity color thresholds.
Actual behavior
None of it is controllable. Every one of those is a literal in the render path of a file the installer owns and overwrites.
Affected components
wheeler/_data/hooks/wheeler-statusline.js (the renderer, and the file users are currently forced to edit)
wheeler/installer.py:362-380 (the copy loop that discards local edits)
- Wherever Wheeler user level configuration is read, for the new setting to live
Acceptance criteria
Scope boundaries
- Do not change the update badge, GSD badge, model, or directory segments.
- Do not change wrapper mode (
--wrap-b64) behavior.
- This issue is only about the context box being configurable, not about which percentage the box should report. That is a separate issue.
Context
- Severity: Medium
- Workaround: Hand edit
~/.claude/hooks/wheeler-statusline.js. This works until the next install or update, then it is silently reverted.
- Session: User wanted the raw context token count alongside the existing bar, in the style of ccstatusline's
context-length widget. Getting to 62.7k (7%) ██░░░░░░░░ took four successive hand patches to the installed hook, all of which are now scheduled for deletion by the next /wh:update.
Problem
The context box rendered by
wheeler-statusline.jshas no configuration surface. The token count, the percentage, the bar, the element order, and the severity color thresholds are all literals inside the render path. A user who wants any layout other than the shipped one has to hand edit the installed hook at~/.claude/hooks/wheeler-statusline.js, and the installer overwrites that file on every install and update (wheeler/installer.py:372-380unlinks the destination and recopies unconditionally), so the customization is silently lost.Notably, the statusline consumes
context_windowfrom the statusline stdin payload but renders only a bar and a percentage. The raw token count is available in that payload and is never shown, which is the single most requested number.Steps to reproduce
~/.claude/settings.jsonhas"statusLine": {"type": "command", "command": "node \"~/.claude/hooks/wheeler-statusline.js\""}.62.7k (7%) ██░░░░░░░░instead of the shipped██░░░░░░░░ 7%./wh:command that changes it. There is none.~/.claude/hooks/wheeler-statusline.js.Error output
There is no error. The failure is silent on both ends: no config surface to discover, and no warning when the hand edit is discarded.
The shipped render path, with every format decision inlined:
Fields available in the statusline stdin payload but unused by the renderer:
Expected behavior
A user can change the context box presentation through Wheeler, without editing an installed file, and the choice survives install and update. At minimum the following should be controllable: whether the raw token count is shown, whether the percentage is shown, whether the bar is shown, the order of those elements, and the severity color thresholds.
Actual behavior
None of it is controllable. Every one of those is a literal in the render path of a file the installer owns and overwrites.
Affected components
wheeler/_data/hooks/wheeler-statusline.js(the renderer, and the file users are currently forced to edit)wheeler/installer.py:362-380(the copy loop that discards local edits)Acceptance criteria
~/.claude/hooks/.62.7k,1.2M).context_windowor its subfields are absent, rather than printing a blank or broken segment.Scope boundaries
--wrap-b64) behavior.Context
~/.claude/hooks/wheeler-statusline.js. This works until the next install or update, then it is silently reverted.context-lengthwidget. Getting to62.7k (7%) ██░░░░░░░░took four successive hand patches to the installed hook, all of which are now scheduled for deletion by the next/wh:update.