What Claude Code's Agent View lists, what it leaves out, and how to see the rest

Posted on Oct 29 • Originally published at ccdeck.dev • AI-assisted

This article was prepared with AI assistance, using ccdeck’s source code and documentation to check the technical details.

I build ccdeck, one of the tools that shows what Agent View leaves out, so read its part as one side of the comparison; the short version, with every source, is at ccdeck.dev/agent-view. Agent View is quoted from Anthropic's documentation as I read it on 29 October 2026, the --json output is from Claude Code 2.1.312, and ccdeck is described as of 3.49.1.

From the docs: "Agent view, opened with claude agents, is one screen for all your background sessions: what's running, what needs your input, and what's done." It is new, and the docs say so up front: "Agent view is in research preview. The interface and keyboard shortcuts may change as the feature evolves."

The sessions in Agent View are not running in your terminal. A supervisor process runs them, "so they keep working after you close agent view or your terminal"; Claude Code starts it the first time you background a session or open agent view. Each session is its own Claude Code process under it, and in a git repository each one edits files in its own worktree by default. State lives under your config directory: the supervisor's log in ~/.claude/daemon.log, the list of running sessions in ~/.claude/daemon/roster.json, and each session's state in ~/.claude/jobs/<id>/.

Two consequences matter for what comes next. A background session "reads its settings from the directory it runs in, the same as if you had started claude there", so your user settings, hooks included, apply to it. And the files under ~/.claude/jobs/<id>/ "are not a stable interface"; the docs point scripts elsewhere, as below.

The same page, in the section on monitoring:

Interactive sessions you have open in other terminals don't appear until you background them. Subagents and teammates a session spawns aren't listed as separate rows.

A row shows "the session's name, current activity, and its age": no spend or quota, while the docs warn that "background sessions consume your subscription usage the same as interactive sessions, so running ten agents in parallel uses quota roughly ten times as fast as running one."

The screen leaves interactive sessions out; the JSON listing does not. In 2.1.312 its help reads: "Print active sessions (interactive and background) as a JSON array and exit". The docs call it "the supported way to read session state from outside Claude Code". Each entry has a kind ( interactive or background ), and while its process is alive a status ( busy, waiting or idle ); a waiting session adds waitingFor, such as permission prompt or input needed.

Every session waiting on you, from any terminal:

claude agents --json | jq -r '.[] | select(.status == "waiting") | [.kind,.name,.waitingFor] | @tsv' Enter fullscreen mode Exit fullscreen mode It lists sessions, not subagents, and it is a snapshot: poll it to keep it current.

A hook in ~/.claude/settings.json applies to every session that reads that file, whichever terminal started it, background sessions included. The Notification event tells you when one stops for you, with a notification_type:

A hook that appends one line per wait to a log file, and prints nothing:

{ "hooks": { "Notification": [ { "matcher": "permission_prompt|idle_prompt", "hooks": [ { "type": "command", "command": "jq -c '{at: (now | todate), session:.session_id, cwd, type:.notification_type, message}' >> ~/.claude/waiting.log" } ] } ] } } Enter fullscreen mode Exit fullscreen mode Notification hooks "can't block or modify notifications", so this one can only observe.

Hooks from settings files "also run inside subagents", and tool events such as PreToolUse carry agent_id and agent_type when a subagent made the call. SubagentStart and SubagentStop mark each one's life. That is enough to draw a session as the tree it is.

Neither listing has it. Codex CLI has its own codex agents dashboard, and writes every session to a rollout file under ~/.codex/sessions.

ccdeck is a free, open-source dashboard that runs on your machine. Its first run adds a hook to ~/.claude/settings.json for up to twelve events, Notification among them, so every Claude Code session that reads that file reports to it, and you keep starting sessions the way you do now.

Each subagent is a card of its own, joined to its session by a line, with its last four tool calls beside it while they run:

Demo data. One session with four subagents, of which only the reviewer is still running.

The topbar names the sessions stopped on you, with how long each has waited and on what, and the session list puts prompts and questions first, then finished turns, longest wait first. The limits: that list is Claude Code only, and the tool name beside a wait is ccdeck's inference, not something Claude Code reports. In a terminal, ccdeck sessions prints the same list.

Codex sessions sit on the same canvas, read from their rollout files with no hook, and a Codex sub-agent whose rollout names its parent gets a card joined to it. Codex writes no approval request there, so a running Codex session that can ask for one says approvals not visible rather than leaving the waiting list to look complete.

A background session's own line. For a session started with claude --bg or from claude agents, ccdeck also reads its folder in ~/.claude/jobs and shows Claude Code's own line for it: the question it is stuck on and the reply Claude Code suggests, or the headline of what it got done. No model is called for it. Because those files are not a stable interface, ccdeck treats every field as untrusted, and a file it cannot parse means no line for that session.

Beside that, an estimated spend per session (the tokens priced at API rates) and the Claude and Codex quota windows as they refill.

They do not collide. A read-only hook answers nothing, so it cannot change what Agent View or its sessions do, and because background sessions read your user settings, the sessions Agent View runs report to the hook too.

The split I would suggest: dispatch and reply in Agent View; poll claude agents --json if all you need is "who is waiting, in any terminal"; and add a hook, your own or a dashboard's, when you want subagents, Codex or spend beside them.