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

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.

What Agent View is

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."

What it does:

• Start work. Type a task and press Enter, and a new background session starts on it. From a shell, claude --bg "<prompt>" does the same.
• Sort by who needs you. "Agent view groups sessions so the ones that need input are at the top." The Needs input group covers questions, permission decisions and other prompts only you can answer.
• Reply in place. Space on a row opens a peek panel with "the exact question it's asking, above the reply input"; type a reply and press Enter to send it without leaving agent view.
• Attach and leave. → attaches to the whole conversation; ← on an empty prompt detaches, and the session keeps running.

How it works underneath

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.

---

What it doesn't list

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.

So three things stay off the screen:

• Sessions in your other terminals. A claude in a tmux pane, an editor's terminal or a second window is invisible until you run /bg in it or press ← on an empty prompt. That turns it into a background session, run by the supervisor: a change to how it runs, not only to where you see it.
• Subagents. A session that fans out into four subagents is one row.
• Codex. Agent View lists Claude Code sessions.

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."

---

Seeing the rest with Claude Code alone

Your other terminals: claude agents --json

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'

It lists sessions, not subagents, and it is a snapshot: poll it to keep it current.

Waiting sessions as they happen: the Notification hook

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:

• permission_prompt: "Claude needs you to approve a tool use", once the prompt "has waited about six seconds". In a terminal each keystroke defers it; for an immediate signal, the docs point to PermissionRequest.
• idle_prompt: Claude "finished responding about 60 seconds ago and you haven't typed since".
• agent_needs_input and agent_completed: for background sessions, and only "while agent view is open in a terminal".

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"
          }
        ]
      }
    ]
  }
}

Notification hooks "can't block or modify notifications", so this one can only observe.

Subagents: tool events carry who made them

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.

Codex

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

---

One tool that does the hook route: ccdeck

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.

What it cannot do, by design:

• Reply, start or attach. Its hook is a one-way forwarder: it posts the event, exits 0 and writes nothing to stdout, the two channels a Claude Code hook has to answer with. You answer in the session's terminal, or in Agent View. The one thing the deck runs is Continue, on a background session whose turn stopped on an error such as an expired login or a usage limit: it stops the session if Claude Code still lists it, then runs claude --resume <id> --bg "Continue from where you left off." in its folder, at your press or, with a setting you turn on, once per stop.
• Record while stopped. The hook forwards to a running deck and keeps nothing; events sent while no deck runs are gone.

---

Side by side

	Agent View	claude agents --json	A hook-based dashboard (ccdeck)
Sessions in other terminals	Only once backgrounded	Yes, with status	Yes, whichever terminal started them
Subagents	Not as rows	No	Each one a card, joined to its session
Codex CLI	No	No	Yes, from its rollout files
Waiting on you	Needs input group	status: waiting and waitingFor	Claude Code only, longest wait first
Reply, start, attach	Yes	No (other claude commands attach and stop)	No; Continue resumes a background session that stopped on an error
Spend and quota	Not in the list	No	Estimated spend per session; quota windows

Use them together

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.