Fleet and approvals
The live roster of agents, the approval inbox, and why the count can lie.
FleetView is the roster of agents across the workspace, with the approval inbox beside it. It is where multi-agent work becomes supervisable — and where optimistic reporting does the most damage.
What it shows
| Element | Contents |
|---|---|
| Fleet cards | Agents, their providers, and status |
| Approval inbox | Actions waiting on your consent |
| Remote inbox | Messages arriving from peer machines over LAN Link |
| Spoken status | Optional audible fleet summary |
The count can overstate
WARNING
FleetView has a known defect where the roster shows more agents live than actually exist. Treat the count as a hint, and confirm against task state before concluding work is in progress.
nala tasks list
This is not a cosmetic issue. A roster that reads "6 agents working" when three exist changes what you decide to do next, which is why it is called out here rather than buried. See known limitations.
Busy is not progress
Four different things can look identical from a fleet view:
| Looks like work | Actually |
|---|---|
| Output scrolling | Could be a provider's own idle chatter |
| Process alive | An agent can hold a session open and advance nothing |
| Message sent | May be queued, or staged and never submitted |
| Task assigned | Says nothing about whether a turn started |
The reliable signal is task state. See
delivery lifecycle for the six real delivery
states, including needs_enter — text sitting in a composer that will never run.
The approval inbox
Approvals from any agent collect here, so supervising several agents does not mean watching several panes.
IMPORTANT
An inbox makes approvals easy to clear in bulk. That is exactly the risk. Each approval is a decision about your machine or your repository; batching the interface should not batch the judgement.
Read the action, check it matches the task you assigned, then decide.
Remote inbox
Messages from peer machines arrive here and render as text only. They are never pasted into a PTY and never routed to an execute path, so a peer cannot cause your machine to run something by messaging you.
Supervising well
- Give each agent a scope that maps to a worktree, so diffs stay reviewable.
- Check task state before intervening; a slow queue is not a stuck agent.
- Verify work yourself. Agent-reported success is not evidence.
- Stop sessions you no longer need — a pane that looks closed may still have a live process behind it.