How to Monitor Multiple Coding Agent Sessions Without Babysitting Them

Published August 29, 2026 · by the AQ team

Monitoring multiple AI coding agent sessions comes down to two moves: make every agent push a signal the moment it changes state (finished, blocked on a question, failed), and keep one surface where you can see every session's state at a glance. If you are polling terminals by hand, alt-tabbing through windows to check whether Claude Code is still thinking, you are doing the scheduler's job yourself, and it caps how many agents you can usefully run at two or three.

The only four states that matter

A running agent session is in one of four states, and your monitoring setup exists to tell them apart without you reading terminal output:

• Working. Running tools or generating. Needs nothing from you; any minute spent watching it is wasted.
• Blocked on you. A permission prompt, a clarifying question, a plan awaiting approval. This is the state that costs throughput: an agent can sit blocked for forty minutes because its question scrolled by in a window you were not looking at.
• Done. The turn finished. "Done" is a claim, not a fact: the work still needs a diff read and a test run. Verifying agent work is its own discipline.
• Dead. The process exited, the SSH connection dropped, the laptop slept. The worst version is the silent one you discover an hour later.

Notice what is not on the list: progress. Watching an agent stream tokens feels like supervision but conveys almost nothing you can act on. The useful question is not "what is it doing", it is "did anything change state since I last looked".

Rule one: agents push, you never poll

Every mainstream agent CLI can run a command of yours when something notable happens. Wire these up before you scale past two sessions.

Claude Code has a hooks system. Two hooks matter, as of August 2026: the Notification hook fires when Claude Code sends a system notification and supports matchers for the type, including permission_prompt and agent_needs_input (the "blocked on you" states) and agent_completed, so "blocked" and "finished" can go to different channels. The Stop hook fires when Claude finishes responding and receives the final assistant message, the right place for a "here is what just landed" ping. The Claude Code notifications guide walks through the configuration.

Codex CLI has a top-level notify setting in its config file: a command as an argv array, to which Codex appends a JSON payload describing the event when a turn completes:

# ~/.codex/config.toml (top-level keys go before any [table] sections)
notify = ["notify-send", "Codex"]

# Codex invokes it as:
# notify-send Codex '{"type":"agent-turn-complete","turn-id":"...", ...}'

As of August 2026 the only documented event type is agent-turn-complete, so Codex can tell you it finished but not that it is waiting on a permission prompt; pair it with the terminal-level signals below for the blocked state.

Where the pings land is up to you: desktop notifications at your desk, a Slack webhook or phone push when you have walked away. Once the signal travels to you, checking on agents becomes interrupt-driven instead of a background loop in your head.

What tmux gives you for free

If your agents run in tmux (and for anything long-running they should, since tmux is what lets a session survive a dropped connection), the multiplexer itself is a serviceable monitor. Three window options do most of the work, as of August 2026:

• monitor-activity flags a window in the status line when a background window produces output: a coarse "something happened here" marker.
• monitor-silence flags a window after N seconds of no output. The underrated one for agents: a window silent for ten minutes is done, blocked, or dead, and all three deserve a look.
• Bell alerts flag a window when a program rings the terminal bell, which several agent CLIs do on completion or when they need input.

# In .tmux.conf: flag windows on activity, and after 3 minutes of silence
setw -g monitor-activity on
setw -g monitor-silence 180
set -g visual-activity on

The flagged-window markers in the status line then act as a tiny dashboard: one glance tells you which of your six agent windows changed state. Purpose-built tooling has grown on top, such as tmux-agent-sidebar, an open-source sidebar that watches Claude Code, Codex, and OpenCode panes across all tmux sessions and shows per-agent status without switching windows, as of August 2026. The limits are structural: tmux state is per-machine and in-memory, and nobody else can see your status line without SSH access to your box.

What the vendors give you

Each major agent now ships some version of a session dashboard, with one shared caveat: each shows only its own agents. All of the following is as of August 2026. Claude Code's agent view (opened with the command claude agents, in research preview) is one screen for every background session on the machine, grouped into needs input, working, ready for review, and completed; the /bg command backgrounds a running session, the --bg flag starts one backgrounded, and permission prompts can be answered inline. GitHub Copilot's sessions are tracked from an agents panel reachable from any page on GitHub, with logs showing the agent's reasoning and tool use. Cursor's cloud agents are monitored from cursor.com/agents in any browser, plus an iOS app. Codex cloud tasks show live progress and logs in ChatGPT and the IDE extension.

The gap appears the moment you mix vendors, which most teams running parallel agents do: Claude Code for one kind of task, Codex for another. Now you have two dashboards, plus tmux for whatever runs on your own boxes, and none of them can see the others. That fragmentation, not any single tool's weakness, is why monitoring several agents still feels like work: the pieces exist, the single pane does not.

Practices that survive contact with five agents

Cap concurrency at your review capacity, not your spawn capacity. Starting a sixth agent takes ten seconds; reviewing its output takes twenty minutes. Most developers plateau at three to five useful concurrent sessions, and the binding constraint is attention: see how many coding agents one developer can actually run.

Batch your check-ins. Respond to blocked-state pings promptly (cheap to unblock, expensive to ignore) and sweep completed sessions in batches between your own focused work.

Isolate sessions. One git worktree per session means a red test run belongs to exactly one agent; shared checkouts turn every anomaly into a forensic exercise. And name windows after tasks: fix-auth-refresh at a glance beats reading scrollback.

Overnight runs raise the stakes, because nobody answers a 3am permission prompt: pre-authorize what the agent will need and read the record in the morning, as the overnight runs guide covers.

The missing layer: anyone else's eyes

Everything above is single-player: your tmux flags live on your machine, your hooks ping your phone, your agent view shows your sessions. If you are out at lunch when an agent gets blocked, the session waits for you specifically, even if a teammate had the context to answer in seconds. The data says teams mostly have not solved this: 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. Monitoring that only one person can do is a big part of why.

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's job is collapsing the fragmented monitoring surfaces into one place that the whole team can see.

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. That changes the monitoring problem in three ways. Sessions survive your laptop closing and resume from any device, so "dead because my machine slept" stops being a state you watch for, and glancing at a session from your phone works. Every workspace is one isolated git worktree with its own live terminal, PRs tracked per workspace, and a live preview, so checking on an agent means a browser tab, not SSH. And monitoring stops being single-player: teammates open the same workspace and watch the same live session, so whoever has context can look at a blocked agent even when its owner is out (typing into someone else's terminal is delegated, the owner approving a control request in one click), while visibility stays owner-managed: team-visible, or private and shared with specific people. When a session should change hands entirely, handing off a live agent session covers the etiquette.

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, rate locked for your first 12 months.

Plainly: hooks, tmux flags, and each vendor's dashboard will get one disciplined developer to four or five well-monitored sessions; if that is your situation, wire them up and stop there. AQ earns its place when the sessions should be visible to more people than the one who started them.