Session monitoring in claude-view relied on heuristics — matching processes to sessions by working directory and timing. It worked most of the time. But “most of the time” breaks down when you run three Claude Code instances in the same repo, or when a session restarts faster than the polling interval. v0.26.0 replaces heuristics with process IDs and closes five lifecycle gaps that caused phantom sessions, missed state transitions, and stale status badges.

PID-based session identity

Previously, the Live Monitor matched sessions to processes by correlating the session’s cwd with running claude processes. This breaks in common scenarios: monorepo developers running multiple agents in the same directory, sessions that restart between scan intervals, or worktree-based workflows where the same project appears at multiple paths.

Now, each session is identified by its process ID at creation time. The monitor reads the PID from the session’s lock file and tracks it through the process lifecycle. When the process exits, the session transitions to its terminal state immediately — no polling delay, no heuristic matching, no ambiguity.

The five gaps this closes:

Phantom sessions — a crashed process left a stale lock file, so the monitor showed a “running” session with no process behind it. Now, PID existence is checked directly.
Split identity — a restarted session got assigned a new monitor entry instead of updating the existing one. PID continuity prevents this.
Delayed transitions — the gap between “process exited” and “monitor notices” was up to one scan interval (2s). Now it’s event-driven.
Cross-contamination — two sessions in the same directory could swap identities when one exited and another started. PIDs are unique per session.
Orphaned watchers — file watchers for exited sessions weren’t cleaned up, slowly leaking resources. PID-based lifecycle ties cleanup to process exit.

Batch process scanning

The monitor used to call ps once per tracked session — if you had 20 sessions, that was 20 subprocess spawns every scan interval. On macOS, ps is fast, but 20 invocations every 2 seconds adds up, especially on laptops where CPU cycles directly translate to battery drain.

v0.26.0 collects all tracked PIDs and checks them in a single batch ps call. The process tree classifier — which determines whether a PID is a Claude Code session, a subprocess, or unrelated — now operates on the full process table in one pass. This reduces scan overhead from O(n) subprocess spawns to O(1).

Live statusline via SSE

Claude Code has a statusline — the text at the bottom of the terminal that shows what the agent is currently doing: reading a file, running a command, thinking, waiting for permission. This information was only visible in the terminal where the session was running.

v0.26.0 broadcasts statusline updates to the Live Monitor via Server-Sent Events. The existing SSE connection that carries session state transitions now also carries statusline payloads. The chat panel receives this context too, so when you’re chatting with an agent, you can see “Reading src/lib/auth.ts” or “Running tests” without switching to the terminal.

This is particularly useful for long-running agent sessions where you’ve backgrounded the terminal. Instead of switching back to check if the agent is stuck or making progress, the Live Monitor shows the current activity in real-time.

Opt-in telemetry

v0.26.0 adds PostHog telemetry with a consent flow. On first launch, you’re asked whether to opt in. The choice is persisted and can be changed in settings. If you opt in, claude-view reports anonymous usage events — which features are used, session counts, error rates — that help prioritize development.

The PostHog API key is baked into release builds at compile time, so telemetry works without any environment variables or configuration. If you opt out, no events are sent — the integration is fully gated on the consent flag, not just filtered server-side.

Update

npx claude-view@latest