claude-code - 💡(How to fix) Fix [FEATURE] surface live context % in claude agents pane (statusLine / hook)

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Fix Action

Fix / Workaround

  • tried a per-turn hook (UserPromptSubmit / PostToolUse) thinking i could walk up to the tmux pane from the hooks pid — process tree roots at launchd via --bg-pty-host, no tmux ever reachable
  • considered a "most recent activity globally within N seconds" heuristic across all live sessions, but fragile if multiple sessions are concurrently active
  • current workaround is rendering blank ctx% in agents-view panes (honest "i cant tell" beats confidently-wrong, but loses the signal)

CC 2.x is iterating agents-view actively — happy to test patches behind a feature flag if helpful. the statusLine contract is already well-documented; option 1 is probably a few-line change in whichever process owns the agents-view pane render loop.

RAW_BUFFERClick to expand / collapse

Preflight Checklist

Problem Statement

i use a custom statusLine command that writes per-pane ctx% / 5h% / 7d% to a sidecar file, and a tmux HUD reads from it. its the single most useful signal i have for catching compaction risk during long sessions before it fires.

works fine for normal claude invocations. but theres no path to get the same data inside a claude agents pane:

  • statusLine never fires for the pane (neither for the orchestrator picker nor when a sub-chat is focused)
  • the focused sub-chats are backgrounded by the daemon (claude --bg-pty-host / --bg-spare), so their process tree roots at launchd. no tmux ancestor anywhere in the chain
  • the only tmux-attached process is the agents picker itself, which fires SessionStart once and then nothing per-turn

i verified this empirically with a probe hook that logged session_id, transcript_path, $TMUX_PANE, and the full PPID chain for every hook event. confirmed the topology split: the process with pane context fires only SessionStart, the processes with per-turn hooks have no pane context.

Proposed Solution

any of these would solve it (in order of preference):

  1. fire statusLine in the agents-view pane on each focused-session turn — simplest, matches the existing per-pane contract. JSON payload already has everything needed.
  2. expose the currently-focused session_id via env var or sidecar file owned by the picker process — i can do the rest myself (read transcript_path, scrape usage). env var on the picker process is fine; a /tmp/.claude_agents_focus_<picker_pid>.json file would also work.
  3. fire a hook event when focus changes inside agents-view — same data, different shape. would let me write the sidecar from hook context.

Alternative Solutions

  • tried a per-turn hook (UserPromptSubmit / PostToolUse) thinking i could walk up to the tmux pane from the hooks pid — process tree roots at launchd via --bg-pty-host, no tmux ever reachable
  • considered a "most recent activity globally within N seconds" heuristic across all live sessions, but fragile if multiple sessions are concurrently active
  • current workaround is rendering blank ctx% in agents-view panes (honest "i cant tell" beats confidently-wrong, but loses the signal)

Priority

Medium - Would be very helpful

Feature Category

Interactive mode (TUI)

Use Case Example

  1. tmux pane running claude agents
  2. drill into a sub-chat with right-arrow, work through a long task
  3. context window fills up; HUD ideally shows ctx% creeping up so i can compact before forced compaction fires
  4. today: HUD column is blank in this pane, no way to see compaction risk approaching
  5. with any of the proposals above: HUD updates per turn, same as a normal claude pane

Additional Context

CC 2.x is iterating agents-view actively — happy to test patches behind a feature flag if helpful. the statusLine contract is already well-documented; option 1 is probably a few-line change in whichever process owns the agents-view pane render loop.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING