Feature request: statusLine.refreshInterval for idle auto-refresh

Feature request: statusLine.refreshInterval for idle auto-refresh

Problem

Claude Code's statusLine command only runs on message/tool events. Statusline scripts that display time-sensitive values, most importantly rate-limit countdowns (Session Limit: 51% (reset 27m), Weekly Limit: 7% (reset 6d 3h)), visibly freeze the moment a user stops interacting. A user sitting in a Claude Code session for 30+ minutes of reading or thinking sees a "reset 27m" that hasn't ticked down at all, or worse, is negative by now.

The displayed values are computed live from resets_at epoch timestamps inside the script, so the data side is fine. The freeze is purely on the UI redraw side. Claude Code doesn't invoke the command again until the next event.

Why workarounds don't solve this

• Hooks (PreToolUse, PostToolUse, SessionStart, etc.) fire on events, not timers. No way to self-trigger a redraw.
• External menu-bar / tmux bars (SwiftBar, xbar, tmux status-right) can auto-refresh on their own cadence, but they live outside Claude Code's UI. Users looking at the terminal pane still see stale countdowns.
• ScheduleWakeup / CronCreate can fake it by firing dummy turns, but consumes tokens per wake-up and clutters the transcript.

None of these covers "fresh statusline inside every Claude Code terminal window."

Proposed solution

Add an optional refreshInterval (or pollInterval) field to the statusLine config block in settings.json:

{
  "statusLine": {
    "type": "command",
    "command": "/Users/me/.claude/statusline/statusline.sh",
    "refreshInterval": 60
  }
}

Value in seconds. When set, Claude Code re-invokes the command every N seconds while the session is active, even when idle. Existing event-based invocations continue to fire as normal (so users with dynamic rate-limit data get the fresher of the two).

Sensible defaults: minimum 15s (to prevent abusive configs), no default (backwards-compatible; absence preserves current behavior).

Use cases beyond rate limits

• Git branch changes detected in a side project (statusline reflects git rev-parse --abbrev-ref HEAD freshly)
• Live token cost accrual if displayed
• Active pipeline/build status polled from a local cache
• Any clock or countdown

Priority

Low severity (not blocking anyone), but high delight. The kind of polish that makes the terminal UI feel alive rather than frozen. Every statusline user who displays time-sensitive data hits this.