Statusline stops being invoked for one session and never recovers

What happened

With several Claude Code sessions open in separate terminal panes on one machine, the custom
statusline in one pane disappears completely — not a stale frame, nothing at all — and never
comes back for the life of that session. Other panes on the same machine, same settings.json,
same statusline command, keep rendering normally.

The statusline command is not failing. It stops being invoked.

Evidence

I instrumented the statusline command to write a timestamp file on every invocation (one before any
work, one after stdout is written), then watched two live sessions simultaneously for 60 seconds:

t+5s   healthy[at=…889681 done pid18952]   affected[at=…704261 done pid3400]
t+15s  healthy[at=…899686 done pid20496]   affected[at=…704261 done pid3400]
t+25s  healthy[at=…909706 done pid16240]   affected[at=…704261 done pid3400]
t+35s  healthy[at=…919718 done pid11160]   affected[at=…704261 done pid3400]
t+45s  healthy[at=…929713 done pid5844]    affected[at=…704261 done pid3400]
t+55s  healthy[at=…939737 done pid18984]   affected[at=…704261 done pid3400]

• Healthy session: invoked every 10.000s exactly (matching refreshInterval: 10), a fresh

child pid each time.

• Affected session: zero invocations, frozen on a pid from minutes earlier. By the end of the

investigation it had gone 449 seconds without a single invocation while the session was alive,
visible, and rendering everything else normally (the spinner and token counter were updating).

Ruled out on my side

The statusline command is a small Node.js script. I checked all of these before filing:

| check | result |
|---|---|
| output for the affected session | correct, 162 bytes |
| exit code on malformed stdin (empty, truncated JSON, model: null, no workspace, nonexistent cwd) | exit 0 with output in every case |
| full invocation time | 200–250 ms (~105 ms of which is bare node startup) |
| hung child process holding the pipe | none — last statusline pid no longer exists |
| background work it spawns | detached: true, stdio: 'ignore', unref() — never holds stdout |
| rewriting settings.json to trigger a config reload | does not re-arm it (byte-identical rewrite, 30 s watch, no invocation) |

So the command cannot have been disabled by erroring or by hanging, and a config reload does not
revive it.

Expected

If the statusline command stops being driven for a session, it should resume — at minimum on the next
turn, on a config reload, or when the session goes idle and refreshInterval next fires.

Actual

It never resumes. Restarting the session is the only recovery I have found.

What I could NOT find

No deterministic repro, and I would rather say so than guess. Things that are not the
distinguishing factor, since ruling them out may save someone time:

• Not a long-running background task. The affected pane had one (footer showed ← 1 agent) — but

so do the healthy sessions on the same machine, permanently. Sessions with an identical background
task render fine.

• Not the working directory, the account, or the settings — shared across affected and healthy

panes alike.

• Not session age or ordering — the affected session was neither the oldest nor the newest.

The one difference I could observe is that the affected session was mid-turn and streaming tokens
when the statusline stopped, while the healthy one was idle. That is a correlation from a single
observation, not a repro: the statusline never resumed afterwards either, so "busy" cannot be the
whole story — a busy session eventually goes idle, and this one still never rendered again.

One inference, offered as inference only: if the statusline re-triggers on message/token-usage changes
behind a debounce and aborts the in-flight run when a new trigger arrives, a continuously-streaming
session would re-trigger constantly. It is easy to imagine that leaving the per-session refresh in a
state it never leaves. I could not verify this from outside the process, and I am not claiming it.

Environment

• Claude Code on Windows 11
• Several sessions running concurrently in separate Windows Terminal panes
• statusLine: { "type": "command", "command": "node \"…/usage-monitor.js\" --compact", "refreshInterval": 10 }
• The statusline script is from an open-source wrapper (arc); it is plain Node with no dependencies,

and the checks above were run against the exact deployed copy.

Happy to run any instrumentation that would help narrow it — I already have per-invocation timestamps
on both a healthy and an affected session and can add whatever else is useful.