Feature Request - refresh status line on an interval

Resolved 💬 20 comments Opened Aug 13, 2025 by dhughes Closed Apr 11, 2026

It would be very helpful if the statusline script could be configured to automatically refresh on an interval. Right now it only updates after you interact with Claude.

As an example, I added a statusline script that will check Github to see the status of the PR associated with the branch I'm working on. I would like that status to update every minute or so, even if there hasn't been any activity in Claude code. I often leave it Claude code idling in a terminal window and hop back to it when I need it. If I haven't interacted with Claude code for a while, the status line can be out of date.

I imagine a refreshIntervalSeconds setting like this:

{
  "statusLine": {
    "type": "command",
    "command": "ruby ~/.claude/statusline.rb",
    "refreshIntervalSeconds": 30
  }
}

This would cause my statusline script to be run at least every 30 seconds, even if there hasn't been any activity within my Claude code session.

View original on GitHub ↗

20 Comments

coygeek · 10 months ago

Hey, this is a really interesting idea. I can see how that would be super useful, especially for your use case of monitoring a PR status.

I just looked through the documentation to see if this was possible, and you're spot on about the current behavior. The statusline documentation page says:

The status line is updated when the conversation messages update

So it's definitely tied to activity in the conversation right now. I also checked the changelog and the settings.json reference, and there's no mention of a refresh interval setting like the one you proposed (which seems like a perfect way to implement it, by the way). The most recent changelog entry for the status line (v1.0.85) was just to add cost info to the input JSON.

I was thinking about potential workarounds, maybe with hooks, but all the hook events seem to be tied to specific actions (like PreToolUse, SessionStart, etc.) rather than a timer, so that doesn't look like an option either.

The only thing I could think of is that a constant background refresh might be tricky to implement without adding performance overhead, especially for scripts that make network calls like yours. But being able to configure the interval, like you suggested, would probably put that in the user's control.

Anyway, just wanted to add my +1 to this. It would make the status line a lot more powerful for dynamic information. Hopefully the team sees this

sirmalloc · 10 months ago

I'm all in favor of a configurable refresh rate in milliseconds. It seems v1.0.88 runs the statusline constantly (I was even able to play a movie in the statusline), but this has definite performance impacts, especially if the status line is called via a tool like npx or uvx.

coygeek · 10 months ago

I love the movie hack.

dhughes · 10 months ago

Was there an update that made the status line refresh on an interval? I've only seen my status line updating after Claude finishes with a prompt. I just did a test with v1.0.89 to show the date with seconds in the status line and it's not updating at all unless I have Claude do something. When I run a prompt, I do see the status line updating from time to time. I'm guessing it runs the status line update every time a hook is executed.

sirmalloc · 10 months ago
Was there an update that made the status line refresh on an interval?

v1.0.88 continuously called the statusline, then they 'fixed' it by reverting the behavior in v1.0.89. I understand why it was necessary to revert, just wish it was configurable.

hershey-g · 7 months ago

I would love this.

gezibash · 6 months ago

+1 for a configurable refresh interval

Use cases where periodic refresh improves Human-Agent Interaction:

  1. Session duration - Helps maintain awareness of how long an agent has been working, especially during autonomous multi-step tasks.
  2. Background task status - Builds, test suites, or deployments running via run_in_background. No way to see completion without sending a message.
  3. Git sync status - Teammates pushing changes or CI completing affects the shared codebase. Stale indicators mean the human can't trust the displayed state.
  4. System health - Battery, memory, or disk pressure during long autonomous runs. The agent may be working fine, but the system is about to interrupt it.
  5. External integrations - MCP servers, webhooks, or any external state that changes independently of the conversation. The statusline is the natural place to surface these.
  6. Cost/token tracking - During long tool chains, usage accumulates but the display lags. Real-time awareness helps humans decide when to intervene or let the agent continue.

The statusline is the human's peripheral awareness of agent state. A configurable refresh interval (default 30s, user-adjustable) would make it a reliable dashboard rather than a snapshot that's often stale.

scottli139 · 5 months ago

确认这个问题仍然存在

我在 Claude Code v2.1.19 上也遇到了同样的问题。

我的配置

"statusLine": {
  "type": "command",
  "command": "~/.claude/statusline-command.sh",
  "padding": 1,
  "refreshInterval": 1000
}

实际行为

  • ✅ 状态栏脚本正常执行
  • ✅ 每次有用户交互时,时间会更新
  • 但在空闲时不自动刷新 - 即使设置了 refreshInterval: 1000

我的测试

我使用以下脚本测试过:

#!/bin/bash
current_time=$(date +%H:%M:%S)
current_dir=$(pwd | sed 's|^/Users/build|~|')
git_branch=$(git -c core.autocrlf=false branch --show-current 2>/dev/null | sed 's/^/ on /')
printf '%s | %s%s' "$current_time" "$current_dir" "$git_branch"

直接执行脚本时,时间会正确更新。但在 Claude Code 中,如果不进行任何操作,时间会保持不变,直到有新的输入才会更新。

环境

  • macOS (Darwin 25.3.0)
  • Claude Code 2.1.19
  • Shell: bash/zsh

建议的配置格式

我同意原 issue 提议的配置方式:

{
  "statusLine": {
    "type": "command",
    "command": "~/.claude/statusline-command.sh",
    "refreshIntervalSeconds": 30
  }
}

或者让现有的 refreshInterval(毫秒)配置真正生效。

---

操作系统: macOS (Darwin 25.3.0)
Claude Code 版本: 2.1.19

NoobyGains · 5 months ago

Is there any progress on this, i would really love this to be fixed

CLNMR · 4 months ago

+1!
Any updates?

zachleach · 4 months ago

+1

kovpack · 4 months ago

yes, this would be just awesome, cause in cases with custom status bar and multiple claude instances running in different terminals (with some shared data rendered in this status bar), all status bars in these instances quickly become stale unless i actively do something and the re-render is triggered.

zachleach · 4 months ago

Currently installed tweakcc for this feature -- works great!

yurukusa · 3 months ago

Until status line auto-refresh is built in, here's a workaround:
Workaround — Use a dynamic status line with shell command:
The status line supports shell commands via backtick notation:

// settings.json
{
  "statusLine": "\`date +%H:%M\` | \`git branch --show-current 2>/dev/null\` | \`wc -l < TODO.md 2>/dev/null || echo 0\` TODOs"
}

The shell commands in backticks execute each time the status line renders, which happens on certain events (tool calls, prompt submission, etc.).
For true periodic refresh:
The status line doesn't auto-refresh on a timer, but it re-evaluates when Claude processes events. You can force re-evaluation with a PostToolUse hook that touches a state file:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "*",
        "hook": "bash -c 'date +%s > /tmp/claude-last-activity'"
      }
    ]
  },
  "statusLine": "Last: \`cat /tmp/claude-last-activity 2>/dev/null | xargs -I{} date -d @{} +%H:%M 2>/dev/null || echo --\` | \`git branch --show-current 2>/dev/null\`"
}

Workaround 2 — Use tmux status bar instead:
If you run Claude in tmux, tmux's status bar refreshes on a configurable interval:

set -g status-interval 5  # Refresh every 5 seconds
set -g status-right '#(git -C #{pane_current_path} branch --show-current 2>/dev/null) | %H:%M'
joeyda3rd · 3 months ago

+1

Adding a concrete use case that I think strengthens the case for prioritization.

The prompt cache TTL problem makes this particularly urgent. Anthropic caches conversation context for 5 minutes after the last API call, a cache miss costs meaningfully more, especially in long sessions. A natural pattern is to display a countdown in the statusline so users know whether they're working within a warm cache window.

The problem: by the time the statusline renders (after Stop), the cache was just touched and always reads warm. The countdown only goes stale between events, exactly the window where a timer re-render would help. Without refreshInterval, the display is technically accurate at render time but practically useless as a cache indicator.

Workarounds I've tried: spawning a background process from a Stop hook to write expiry state to disk works for the data side, but can't trigger a re-render, so the display stays stale until the next event fires. Scheduling a sleep + write from inside a hook causes Claude Code to wait on the hook's process group, making the session appear stuck.

The field name refreshIntervalSeconds from the original proposal is clear. An interval floor of ~10s seems right to avoid excess process spawning. No behavior change when the field is absent.

This is the one gap that prevents statusline from being genuinely useful for time-sensitive state.

Aware this likely requires a timer event to be queued into the existing render loop rather than triggering a direct redraw. The goal is additive, not bypassing the debounce mechanism.

EmpireJones · 3 months ago

Similar workaround to the one above: run a background loop that changes the value (e.g. a different suffix) for statusLine.command in ~/.claude/settings.json every x seconds.

0xnfrith · 3 months ago

Strong +1 on this. We're building an agent orchestration system where the statusline is the primary operational dashboard. Use cases that need live rendering:

  • 20+ delamain state machines with health badges that cycle between active/idle/error states. Currently badges only update on assistant turns, so the operator has no visibility between interactions.
  • OBS streaming/recording indicator — LIVE/REC status. Needs sub-second refresh to feel responsive.
  • Channel message counts — unread counts from messaging apps. Stale counts between turns defeats the purpose.
  • Session clock — currently shows the time at last render, not actual current time.

A refreshIntervalSeconds option (even at 5-10s) would transform the statusline from a snapshot into a live dashboard. We've already optimized our script to ~180ms execution with aggressive caching, so frequent refreshes wouldn't be a performance issue.

!Statusline with 20 delamain badges and LIVE indicator

matteocontrini · 3 months ago

This is now available since 2.1.97.

The optional refreshInterval field re-runs your command every N seconds in addition to the event-driven updates. The minimum is 1. Set this when your status line shows time-based data such as a clock, or when background subagents change git state while the main session is idle. Leave it unset to run only on events.

https://code.claude.com/docs/en/statusline#manually-configure-a-status-line

dhughes · 3 months ago

Given that this feature has been implemented, I'm going to close this issue.

github-actions[bot] · 2 months ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.