[FEATURE] Run the custom statusLine command below the dispatch input in agent view (claude agents)

Open 💬 0 comments Opened Jul 9, 2026 by dayano74

Preflight Checklist

  • [x] I have searched existing requests — closest matches are #58523, #68555, and #74139 (all open). This request is narrower and complementary: execute the already-configured statusLine command in the agents dashboard itself. Cross-references below.
  • [x] This is a single feature request (not multiple features)

Environment

  • Claude Code v2.1.205, native install (~/.local/bin/claude), claude agents TUI
  • Windows 11 Pro (build 10.0.26200)
  • statusLine configured in ~/.claude/settings.json: a Node.js script with refreshInterval set; session-state segments maintained by UserPromptSubmit / Notification / PostToolUse / Stop hooks

Problem Statement

The statusLine setting gives every regular session a user-scriptable line under the input box. The agent view dashboard (claude agents) has no equivalent: below the dispatch input there is only the fixed footer (keyboard hints and dispatch defaults), and the configured statusLine command is never executed for the dashboard.

This matters because agent view is exactly the screen where fleet-level, user-defined signals belong. My statusline shows rate-limit bars (5h / weekly / extra usage) and, via Stop/UserPromptSubmit/Notification hooks writing per-session state files, cross-session working / needs-input counts. All of that is invisible on the one screen dedicated to managing multiple sessions.

Verified in the environment above:

  • Instrumented my statusline script to log every invocation (timestamp, ppid, session_id), then launched claude agents for 12 seconds. Every logged invocation belonged to background session processes firing their own refreshInterval timers; not one came from the agents TUI process.
  • The settings schema has no key for this surface — only statusLine (per-session) and subagentStatusLine (in-session agent panel rows).

Proposed Solution

Run a status line command below the dispatch input in agent view. Either of these shapes would work:

  1. Reuse the existing statusLine setting, passing stdin JSON with a fleet-scoped payload instead of single-session data, e.g.:
{
  "hook_event_name": "Status",
  "surface": "agents",
  "cwd": "...",
  "model": { "id": "...", "display_name": "..." },
  "sessions": { "working": 3, "needs_input": 1, "completed": 5 },
  "rate_limits": { "five_hour": {}, "seven_day": {} }
}

A surface discriminator lets one script serve both surfaces.

  1. Or a dedicated agentsStatusLine setting with the same { type: "command", command, refreshInterval } contract, for users who want a different script per surface.

refreshInterval should be honored either way, since the dashboard is often left open unattended.

Alternative Solutions

  • The native header summary and Needs input / Working / Completed groups cover session counts, but user-defined segments (rate-limit bars, cost, anything scripted) have no path onto this screen.
  • subagentStatusLine sounds adjacent but applies to subagent rows inside a session, not the agents dashboard.
  • Watching from a regular session's statusline works (that is what I do today with hook-maintained state files) but requires keeping a second terminal open next to agent view, which defeats the one-screen purpose.

Additional Context

  • Related: #58523 (statusLine never fires for claude agents panes; sidecar/tmux use case), #68555 (customizable agent view rows for quota), #74139 (settings surface for configuring the view). This request is deliberately minimal relative to those: execute the status line command once, for the dashboard footer.
  • Implementation note from the same investigation: headless background sessions already run their refreshInterval statusline timers every N seconds (a node + git spawn per session per tick on my machine) even though nothing renders the output. If that machinery fed the agents footer instead, the feature might come almost for free — and the wasted spawns could be reclaimed at the same time.

View original on GitHub ↗