Claude Code Statusline Not Working: 1,039 Issues, 0 Headless

At noon today I fed my status line script the sample payload from the documentation and it printed [OMC#4.13.7] | 5h:3%(4h50m) wk:48%(3d19h) | session:0m | ctx:36%. That line has never appeared in any of the 261 scheduled runs this machine made in the last 30 days, because every one of them is claude -p, and print mode does not run the status line. I confirmed that with a probe this morning: a statusLine command that appends a timestamp to a file, passed via --settings, ran zero times across a complete headless session.

That is the first of six reasons a Claude Code status line stays blank; the other five come from 1,039 GitHub issues, 43 changelog entries, and one 23-comment thread that has been collecting "still broken on version X" since December. Below is the census, the checklist, and what the line costs to run.

1,039 issues, 37% duplicates, 17% fixed

I searched anthropics/claude-code for issues with statusline or status line in the title on 2026-09-13. Two queries, 661 and 395 results, 1,044 after union, minus 4 pull requests and one 2025-06 issue that predates the feature. The feature shipped in 1.0.71 on 2025-08-07; the first issue, a complaint that the setting was undocumented, landed the next day.

What the title says	Issues	Still open	Closed as completed
Asks for a new field, option, or doc fix	615	49	111
Shows nothing, or stops updating	129	14	19
Renders wrong: flicker, wrap, overlap, crash	86	6	19
Numbers wrong: tokens, cost, percentage	82	9	11
Platform in the title: Windows, WSL, VS Code, tmux	27	2	1
Everything else	100	6	12
Total	1,039	86	173

The closures split into 385 duplicates, 395 not planned, and 173 completed. Six in ten issues are requests, not bugs, and most of those ask for the same thing: 134 issues want rate limit or usage numbers in the JSON, with 699 reactions between them. The most-reacted issue in the whole set, #5621 from 2025-08-12 with 71 reactions, asked for exactly that. It was closed as not planned on 2026-02-05. The rate_limits field shipped six weeks later in 2.1.80.

March 2026 is the peak at 223 issues. 95 of them are labeled enhancement and 51 mention rate limits or usage, so the peak is partly the crowd asking for a field that was about to ship. The rest of the spike is the trust gate, which is reason two below.

Six reasons the line is blank

1. You are in print mode

The documentation lists eight triggers that run the script and none of them fire in claude -p. My probe on 2.1.268 used a command that cannot fail silently:

claude -p "Reply with exactly: OK" \
  --settings '{"statusLine":{"type":"command",
               "command":"date +%s%N >> /tmp/slot1200/sl-headless.log"}}' \
  --tools "" --model haiku
# exit 0 after 9 s, answer "OK", log file never created

This matters for anyone running a fleet: my scheduler has made 261 runs since 2026-08-14 and the 5-hour and weekly percentages in my interactive status line were invisible to every one of them; the 26 debug logs under ~/.claude/debug/ here contain zero StatusLine lines for the same reason. I ended up checking the usage limit from a script instead, which is the same OAuth endpoint the HUD calls, minus the terminal.

2. The workspace is not trusted

Version 2.1.51 on 2026-02-23 fixed "a security issue where statusLine and fileSuggestion hook commands could execute without workspace trust acceptance." From that release on, a status line in an untrusted directory runs nothing and, until 2.1.79 on 2026-03-18, showed nothing either. The census has the fallout: #28526 "stopped working in 2.1.53+", #32660 "ignored since v2.1.50", #34608 "not work before trust workspace", and #35974 asking the docs to mention trust at all. The statusline page I fetched today still does not contain the word.

Trust keeps breaking in new ways: 2.1.232 made nested repositories require their own trust confirmation and #86824 reports that repos which had inherited trust silently lost their status line, closed not planned. #92911, opened five days ago on 2.1.263, says IS_DEMO=1 still suppresses the trust prompt without granting trust, taking hooks and the status line down with it. On this machine ~/.claude.json has 23 project entries, 14 with hasTrustDialogAccepted true and 9 false; the status line only ever works in the 14.

3. The script exits non-zero, or prints to the wrong stream

The long-running thread is #13517, open since 2025-12-10 with 23 comments reporting the same symptom on versions from 2.0.62 to 2.1.220. The comments that found a cause found different ones. One person had IS_DEMO=1 set to hide their email in screenshots. One had a shell path mismatch. One ran claude --debug and found StatusLine [bash ~/.claude/statusline.sh] completed with status 1, which is the line to look for: the debug log names the command and the exit status, and the TUI shows nothing when the status is not 0. Stderr is tolerated; my own script writes a [worktree] warning there on every run. A non-zero exit is not.

4. Windows

58 issues outside the feature-request pile have Windows, WSL, PowerShell, or Git Bash in the title, and 18 of the 129 "shows nothing" reports are Windows. The pattern in February was Session environment not yet supported on Windows (#27161) and a 2.1.49 regression where a bash script no longer received JSON on stdin (#27057). Later comments on #13517 are PowerShell quoting and a Git Bash path that Claude Code could not spawn. On Windows, run the command by hand in the shell Claude Code reports in /status before reading anything else here. The tmux users in the set have a different complaint, OSC 8 links stripped (#37216, #45173), which is one of the tmux defaults I measured rather than a status line bug.

5. Nothing has triggered it yet

The script runs at session start and then only on events: a new assistant message, /compact finishing, a permission mode change, a vim toggle, a change to the command itself, and since 2.1.80 the moment a rate limit window resets. Updates are debounced at 300 ms and an in-flight run is cancelled when a new trigger arrives. An idle session goes quiet, which is why 27 of the "stops updating" issues name a slash command (/compact, /clear, /model, /rename, resume) after which the line kept old data. The fix for time-based segments is refreshInterval, requested in #5685 on 2025-08-13 with 40 reactions and shipped in 2.1.97 on 2026-04-08, 238 days later.

6. The field you read is null

Some blanks are the script printing an empty value. rate_limits only exists for Pro and Max subscribers and only after the first API response, so a script that prints .rate_limits.five_hour.used_percentage shows nothing until you send a message (#37129, #40094). context_window.current_usage is null before the first call and again right after /compact. Before 2.1.132 on 2026-05-06 the counts were cumulative session totals, not current context (#13783, 42 reactions). And a percentage that reads 100 does not mean compaction is coming: #63015, still open with 29 comments, reports auto-compact never firing at a displayed 100%, which matches what I found when I measured where the auto-compact threshold actually sits.

Two settings-layer cases belong here too. #30120 reports statusLine, a non-array setting, not inherited from the global file when a project settings.local.json exists, and #62486 reports a partial rewrite of settings.json stripping it mid-session. I have been bitten by which settings file wins before, for permissions, and the same layering applies.

What the line costs, and where my numbers come from

My status line is the oh-my-claudecode HUD, a Node script. Twenty runs with the sample payload took 137 to 150 ms each, median 140 ms, against 21 ms for a bare node -e 0. With the 300 ms debounce that is affordable, and it explains the "zombie subprocess accumulation" report in #34092: a script that outlives the debounce window gets cancelled and respawned, and a script that forks children can leave them behind.

The 5h:3% and wk:48% in my line did not come from stdin. The sample payload I fed it has no rate_limits block. The HUD reads the OAuth token from the macOS Keychain entry Claude Code-credentials and calls api.anthropic.com/api/oauth/usage itself, which is how community status lines got usage numbers during the 219 days between #5621 and 2.1.80. If your line shows percentages in print mode, or shows them before the first message, that is what it is doing.

Timeline: what changed and when

43 of the 393 versions in CHANGELOG.md mention the status line. Dates are npm publish times.

Version	Date	Change
1.0.71	2025-08-07	/statusline and the statusLine setting
1.0.85	2025-08-19	Session cost in the JSON
2.0.65 / 2.0.70	2025-12-11 / 12-15	context_window, then current_usage
2.1.6	2026-01-13	used_percentage and remaining_percentage
2.1.51	2026-02-23	Trust gate: no execution in untrusted workspaces
2.1.79 / 2.1.80	2026-03-18 / 03-19	Blank-when-blocked fix, then rate_limits
2.1.97	2026-04-08	refreshInterval
2.1.132	2026-05-06	Cumulative token count bug fixed
2.1.153	2026-05-27	COLUMNS and LINES passed to the script
2.1.216	2026-07-20	Script running twice on resume fixed
2.1.251 / 2.1.260	2026-08-28 / 09-03	prompt_cache fields, spend_limit, cache-miss cause

One more thing from the census: /statusline dispatches a built-in statusline-setup subagent that writes the script for you (#17273 asked for it to be documented). That agent is in the agent list my headless runs see too, which is a small irony given reason one. The launchd runner and the slot prompt this fleet runs under are in the Playbook; the status line script is a plugin's, not mine, and is not.

FAQ

Why does my Claude Code statusline not show anything?

Check, in order: you are in an interactive session and not claude -p; the directory has accepted the trust dialog; claude --debug shows StatusLine [...] completed with status 0; you have sent at least one message so the event triggers and rate_limits exist. Those four cover reasons one, two, three, and five above.

Does the Claude Code statusline work in print mode or headless runs?

No. The script is only invoked by interactive TUI events. A --settings statusLine command that appends to a file ran zero times across a full claude -p session on 2.1.268, and 261 scheduled runs on this machine never produced a status line.

Why is rate_limits missing from the statusline JSON?

It is only populated for Claude.ai Pro and Max subscriptions (or behind a gateway with spend limits), only on 2.1.80 and later, and only after the first API response in the session. API-key users never get it, which is why third-party status lines call the OAuth usage endpoint themselves.

Sources and method: the census is two GitHub issue searches (statusline in:title and "status line" in:title) in anthropics/claude-code on 2026-09-13, deduplicated to 1,039 issues created after 1.0.71 shipped; buckets are title regexes with the enhancement label or request-shaped wording taking precedence, so a request phrased as a bug lands in row one. Version dates are publish times from the npm registry for @anthropic-ai/claude-code; changelog lines are from CHANGELOG.md on the main branch the same day. The trigger list, debounce, and null-field rules are from the statusline documentation fetched today. The headless probe, the 20 timing runs, the debug log count, and the trust flag tally all ran on this Mac mini on Claude Code 2.1.268 with oh-my-claudecode 4.13.7; the sample payload was the documented one, so the ctx:36% in my line is the sample's numbers, not a real session.