[FEATURE] surface live context % in claude agents pane (statusLine / hook)

Thanks for using Claude — and especially for pushing on advanced workflows like this. The tmux/HUD integration pattern is genuinely clever, and the context-pressure visibility problem you’re solving is exactly the kind of operational signal that becomes critical in long-running agent sessions.

This matches my understanding of how Agents is currently wired.

In a normal claude session, statusLine and turn hooks execute in the foreground process tree attached to the tmux pane, so deriving pane identity is straightforward. In Agents mode, the actual conversational workers are detached behind the background PTY host (claude --bg-pty-host / --bg-spare), and the visible tmux-attached process is effectively just the orchestrator UI. Once the agent sessions are daemonized, there’s no stable ancestry path back to the originating pane, so hooks lose all pane locality.

I verified the same behavior on my side:

• statusLine never fires for focused agent sub-sessions
• turn hooks execute under the detached daemon tree rather than the interactive pane
• walking PPIDs from hooks dead-ends at launchd/system roots
• the picker pane itself emits only the initial lifecycle events

So today there’s effectively no supported mechanism for:

• mapping a focused agent session back to a tmux pane
• tracking active sub-chat focus transitions
• surfacing per-agent runtime metrics (ctx%, token pressure, compaction risk, etc.) into external HUDs

I strongly agree this is a gap. Context pressure telemetry is materially more important in long-running agent workflows than in single sessions, because compaction becomes both more frequent and less visible.

Of the options you listed, I think these make the most sense architecturally:

1. Fire statusLine for the currently focused agent session inside the agents-view pane

• preserves the existing contract
• zero new API surface
• automatically fixes tmux HUD integrations
• likely the least disruptive behaviorally

1. Expose focused session_id from the picker/orchestrator process

• env var, UNIX socket, or sidecar file would all work
• enough for external tooling to correlate telemetry independently
• cleaner separation between UI and worker processes

1. Emit explicit focus-change hooks

• probably the most extensible long term
• useful beyond tmux (IDE integrations, dashboards, observability tooling)
• could expose {previous_session, current_session} payloads

One additional shape that could work well:

• a lightweight local event stream from the orchestrator process, e.g.

• ~/.claude/agents/events.sock
• newline-delimited JSON
• emits:

• focus changes
• session lifecycle
• context/compaction thresholds
• token usage deltas

That would make external HUDs and integrations dramatically easier without coupling tooling to internal process topology.

As a workaround today, the only semi-viable approach I found was polling the orchestrator TUI state indirectly (screen scraping / tty capture), but that’s brittle and loses the nice hook-based model entirely.

I’d definitely be happy to test patches or prototype integrations if you expose even a minimal focus signal from the agents-view parent process.

The process-tree topology issue you're running into is real -- the background PTY daemon that hosts sub-chat workers has no tmux ancestor, so there is no reliable path to correlate a hook event back to a pane. The PPID chain really does dead-end at launchd.

Of the three options you proposed, option 2 (expose focused session_id from the picker process) is probably the easiest to wire at the tooling layer today, even before a native fix ships:

If the agents picker process writes its own PID to a known path on start (~/.claude/agents/picker.pid or similar), external tooling can use lsof or proc_info to find which TTY that process is attached to, and correlate from there. Fragile, but it works on macOS where lsof -p is reliable.

A slightly more robust interim approach: a wrapper script that starts claude agents and before exec writes its own PID and $TMUX_PANE to a sidecar file. The hook probe you already wrote (logging PPID chains) has everything needed to close the loop -- the hook runs in the daemon process, the sidecar has the picker PID, and you can do a one-time "is the daemon a descendant of the picker?" walk at hook invocation time.

The statusLine gap in agents view is distinct from the hook scope issue and worth tracking separately. The problem is that statusLine fires on the per-turn hook in the conversational worker (daemon process, no pane), not in the picker process (has pane, fires only SessionStart). A minimal fix would be: when the picker process receives a per-turn event from the focused worker, re-fire statusLine in the picker's own process context. That keeps the existing contract without needing to expose a new API surface.

For what it's worth: running context pressure as a metric in an external monitoring layer (polling session JSONL files for cumulative token counts) has been a workable fallback for catching compaction risk, but the latency is 5-10s per poll interval versus the per-turn freshness you'd get from a native statusLine fix. Not the same thing, but it's something until the daemon/picker topology gets cleaner telemetry routing.

Thanks, this is genuinely useful. The confirmation that the PPID chain dead-ends at launchd is worth a lot on its own, bc I'd been assuming I was holding it wrong and there was some ancestor I just hadn't found.

Your statusLine re-fire suggestion is a sharper version of my option 1, and I want to call that out specifically. I'd framed it as "fire statusLine in the agents-view pane," which quietly assumes the pane-owning process can see the focused worker's per-turn events. Framing it as "when the picker receives a per-turn event from the focused worker, re-fire statusLine in the picker's own process context" keeps the existing contract intact and needs no new API surface. That's the one I'd want.

On the sidecar, I'll build the wrapper-script variant, bc it removes the lsof guesswork. I already have $TMUX_PANE at picker start, so writing pane and PID before exec is close to free, and the probe hook I wrote for this report already walks the PPID chain, so the descendant check is a small addition on top. The part I'm less sure about is multiple concurrent claude agents panes, which is my actual setup: two pickers means two sidecars, and the hook has to pick the right one. A descendant walk should disambiguate correctly since the daemons really are parented differently, but I'll find out.

The JSONL polling fallback is the piece I dismissed too early. I'd written it off on freshness grounds, but you're right that 5-10s is fine for what I actually care about, which is noticing compaction risk while there's still room to act rather than watching the number tick. That's a much weaker requirement than per-turn, and it works today, so I'll probably run it while the sidecar gets built. Beats the blank column I have now.

Happy to keep the statusLine gap on this issue and split the hook-scope topology into a separate one if that's cleaner to track. The offer to test a patch behind a flag stands.