[Bug] Custom statusLine command not invoked during task execution; activity indicator overwrites statusline

Bug Description
Title: Custom statusLine command not invoked during task execution; activity indicator overwrites the statusline area

Claude Code version: 2.1.114 (macOS 15 / darwin 25.3.0)

Describe the issue:
When a custom statusLine.command is configured in .claude/settings.json, the command is only invoked while Claude is idle (waiting at the
❯ input prompt). As soon as a turn begins (thinking, tool calls, subagents, long-running tasks), Claude Code stops invoking the statusLine
hook and the on-screen activity indicator (e.g. ✳ Refreshing CLAUDE.md docs… (7m · thinking)) overwrites the statusline region. The
custom statusline is effectively hidden for the entire duration of the turn — which for long tasks can be many minutes.

Reproduction:

1. Configure any statusLine command in .claude/settings.json (simple echo "hello" is enough).
2. Send a prompt that triggers a long-running tool chain.
3. Observe that only ⏵⏵ bypass permissions on shows below the input; custom statusline is missing.

Evidence from my instrumentation:
I logged a timestamp every time the statusLine script was invoked. Across two concurrent sessions in the same project:

• Session 9fb9d075 ran a multi-minute task and had a ~4 minute gap with zero invocations during the task, then resumed invocations when it

returned to idle.

• The script's output at the last pre-task call was perfectly valid (~71 visible chars, all sections populated). So CC is not rejecting

the output — it simply is not calling the command.

Request:

• Option A (preferred): Keep invoking statusLine.command on a cadence during turn execution, so users can see model/context/usage while

long tasks run.

• Option B: Add a setting like statusLine.refreshDuringTurn: true or statusLine.refreshIntervalMs: 5000 that opts into periodic refresh.
• Option C: If the activity indicator is intentionally covering the statusline, render it above (not on top of) the statusline so the

custom output stays visible.

Why this matters:
The statusline exists precisely to communicate slow-moving state (context %, usage %, model). That state is most useful to see exactly
when Claude is doing long work — but that's the one situation where it's hidden. In a 1M-context session, not being able to watch context
fill up during a big task is a real loss.

Environment Info

• Platform: darwin
• Terminal: tmux
• Version: 2.1.114
• Feedback ID: 996a8d6c-1145-4db2-a2bd-76b1d724ef22

Errors

[{"error":"Error: File does not exist. Note: your current working directory is /Users/fikret/Projects/mvc.\n    at call (/$bunfs/root/src/entrypoints/cli.js:4732:7630)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-04-18T20:11:58.810Z"},{"error":"Error: EISDIR: illegal operation on a directory, read '/Users/fikret/Projects/mvc/.claude'\n    at nKH (/$bunfs/root/src/entrypoints/cli.js:1564:144)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-04-18T20:11:58.880Z"},{"error":"Error: ECONNREFUSED\n    at from (/$bunfs/root/src/entrypoints/cli.js:107:7862)\n    at <anonymous> (/$bunfs/root/src/entrypoints/cli.js:115:12925)\n    at emitError (node:events:43:23)\n    at <anonymous> (/$bunfs/root/src/entrypoints/cli.js:114:1149)\n    at emitError (node:events:43:23)\n    at <anonymous> (node:_http_client:253:22)\n    at processTicksAndRejections (native:7:39)\n    at request (/$bunfs/root/src/entrypoints/cli.js:117:2467)\n    at async kn1 (/$bunfs/root/src/entrypoints/cli.js:3089:14374)\n    at async z_7 (/$bunfs/root/src/entrypoints/cli.js:3089:14913)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-04-19T07:44:11.964Z"}]