Claude Code Agent View and Background Sessions, Explained

Published September 10, 2026 · by the AQ team

Agent view, opened with the command claude agents, is Claude Code's built-in dashboard for background sessions: one screen that lists every session running on your machine, shows which are working, which need your input, and which are done, and lets you dispatch new ones without opening another terminal tab. A background session is a full Claude Code conversation that keeps running with no terminal attached, hosted by a per-user supervisor process. The feature shipped as a research preview in May 2026 and, as of September 2026, its one hard boundary is the machine itself: background sessions survive a closed terminal but stop when the computer shuts down or reboots. This guide covers how the whole stack works (agent view, background sessions, Remote Control, and cross-session messaging), verified against Claude Code's own documentation, and where a cloud workspace fits when sessions need to outlive the machine.

What a background session actually is

When you background a Claude Code session, the conversation does not pause. It detaches from your terminal and keeps running as its own process under a supervisor that Claude Code runs per user, separate from any shell. You can close the window, close the shell, or start unrelated work, and the dispatched session keeps calling tools and making edits. Each background session authenticates with your stored credentials and inherits PATH and settings from the shell that dispatched it.

Two details from the documentation matter for planning real work, as of September 2026:

• Idle sessions park themselves. A session that finished its turn and is waiting for input stops its process after about an hour to free resources. The conversation stays on disk and resumes when you attach or reply, so this is invisible in practice unless you pin the session to keep its process alive.
• Parallel edits are isolated by default. Background sessions automatically move into git worktrees under .claude/worktrees/ the moment they try to write files, so two sessions in the same repository do not trample each other's edits. Sessions in non-git directories edit the working copy directly, with no isolation.

Usage is the other planning input: each background session consumes your subscription quota independently, so ten parallel sessions burn roughly ten times the usage of one.

Opening agent view and dispatching work

Agent view is both the monitor and the launcher. Each row shows a session's name, a one-line summary of what it is doing or asking, its age, and a pull request label when the session opened one. Rows move through states: working, needs input, idle, completed, failed, stopped.

# One screen for every background session
claude agents

# Start a background session without opening a tab
claude --bg "fix the failing auth tests"

# From inside a session: keep it running, get your terminal back
/bg

# Reattach later, from any terminal on the same machine
claude attach <session-id>

Inside agent view, typing a prompt and pressing Enter dispatches a new session. Pressing Space on a row peeks at its last output or pending question, and you can type a reply right there without attaching. Pressing Enter attaches fully, and Claude posts a recap of what happened while you were away. Detaching never stops a session.

This is a genuinely good single-player loop: dispatch a bug fix, a test investigation, and a refactor as three rows, then step in only when a row flips to needs input. If you run several tasks this way regularly, the companion guide on running multiple Claude Code sessions in parallel covers the workflow patterns, and monitoring multiple coding agent sessions covers what to watch for once they are running.

What survives, and what does not

The supervisor model draws a precise line, and it is worth knowing exactly where it sits:

The documentation is direct about this: shutting down or restarting your machine stops running background sessions. A session that was mid-task shows as failed when you return, and after 48 hours as stopped. Nothing is lost, but nothing progressed either. The supervisor is a machine-lifetime tool, not an always-on one, which is the difference explored in depth in keeping Claude Code running after closing your laptop.

Steering from another device: Remote Control

Remote Control connects claude.ai/code or the Claude mobile app to a session running on your machine. Execution and filesystem access stay local; the phone or browser is a synchronized window into the session, and the connection is outbound HTTPS only, with no inbound ports. It is available on all plans as of September 2026, though Team and Enterprise organizations have it off until an owner enables it in admin settings.

The same boundary applies, and the documentation names it as a limitation: Remote Control runs as a local process, so if the claude process stops, the session goes offline. For a machine you leave running, Anthropic's own docs recommend starting the session inside tmux or screen so it survives an SSH disconnect. In other words, once you want sessions reachable from anywhere at any hour, you are already building a small server setup around the CLI.

Coordinating sessions on one machine

Two further pieces round out the stack as of September 2026. Cross-session messaging (Claude Code v2.1.224 or later on macOS and Linux) gives Claude two tools, ListAgents and SendMessage, to discover and message your other sessions: same-machine delivery goes over a local per-session socket, and a session can reach your sessions on other machines or on the web only while connected through Remote Control. Messages are plain text, never conversation history, and sessions inside a container cannot reach sessions on the host. Agent teams, an experimental feature that is disabled by default, goes further: a lead session decomposes a project, teammates claim tasks from a shared list and message each other directly. It is the most ambitious of the modes and the least settled; the agent teams guide covers it separately.

Notice the shape of the whole stack: every piece (the supervisor, the sockets, the worktrees, the message routing) is scoped to one person's machine and one person's account. That matches how most agent work happens today. A July 2026 LeadDev analysis of 25,264 agent-generated pull requests across 2,361 popular GitHub repositories found that in 79 percent of agentic PRs the same developer both reviewed and modified the agent's contribution, and only about one in eight workflows involved multiple humans. The tooling is single-player because the workflow still is.

Where AQ fits

AQ is the multiplayer coding harness where engineering teams run AI coding agents like Claude Code and Codex together: shared live terminals, a code editor, and app previews, in your own cloud. In this guide's terms, AQ moves the supervisor's job onto a machine that never shuts down and makes the agent list a team surface instead of a personal one.

Agents run as real CLIs (Claude Code, Codex, Cursor Agent, Kimi, Grok, or plain shells) in persistent tmux sessions on your team's VM, streamed live to the browser. Because the session lives on the VM rather than under a supervisor on your laptop, it survives laptop close, shutdown, and your commute, and you resume it from any device: the overnight run actually runs overnight. Where agent view shows your sessions to you, an AQ workspace is visible to the team (or kept private and shared with specific people): a teammate opens the same workspace and watches the same live session, and typing into someone else's terminal is delegated, with the owner approving a control request in one click. Each workspace gets its own isolated git worktree on a branch named ai/{id}-{slug} with dependencies auto-installed, so the parallel-edit isolation you get from .claude/worktrees/ locally carries over to the team machine. Everyone logs into the CLIs with their own Claude or OpenAI account, and AQ never marks up model usage.

Pricing is two plans: Free is a personal sandbox for one person (AQ creates a private machine in an isolated network, nothing to install, no time limit), and Team is $50 per user per month in early access (standard $200, billed monthly), covering VMs you connect from your own cloud or a dedicated always-on AQ-managed VM in its own isolated network, with your rate locked for your first 12 months.

Plainly: agent view is the right tool for parallel work on a machine that stays open in front of you, and it costs nothing extra. AQ earns its place when the sessions need to outlive the machine, or when the person who needs to see a session next is not the person who started it.