Why Terminal Sprawl is the Real Bottleneck in Agentic Development
Once AI agents write most of the code, the bottleneck in agentic development is no longer typing speed or model quality. It is the human's attention: noticing which agent is waiting, finding the context it needs, and answering it. Terminal sprawl, the pile of tabs and panes that grows with every new session, makes each of those three steps slower, so the fix is better signals and structure, not more terminals.
What does terminal sprawl look like in practice?
Picture a normal Tuesday. Three projects, each with two or three Claude Code sessions: one agent on the backend, one writing tests, one reviewing a plan. That is nine terminals, some in tabs, some in panes, one in a tmux session you forgot about.
Somewhere in those nine terminals, an agent finished its turn twenty minutes ago and is asking whether it may run a database migration. Another one asked a question about the client's spec, and the answer is in a PDF you downloaded last week. A third is happily writing code that a fourth already wrote in a different branch.
None of the agents is slow. All of the waiting is on your side.
Common symptoms:
| Symptom | What it costs |
|---|---|
| You cycle through tabs to check "is anything waiting?" | Minutes per check, many times an hour |
| An agent sat on a permission prompt while you were in another window | Idle time that looks like the agent being slow |
| You can't find the question an agent asked an hour ago | Scrolling, or asking the agent to repeat itself |
| Two sessions solve the same problem | Duplicated work and a merge you didn't plan for |
| You reopen a project and can't remember which terminal was doing what | Rebuilding context from scrollback |
If several of these sound familiar, adding agents will not make you faster.
Why is human attention the agentic development bottleneck?
An agent works in turns. It reads, plans, edits, runs commands, and then it stops: either because it finished or because it needs something from you. That stop is the important moment. The agent cannot continue until a person looks at it.
With one agent, this is fine. With nine, each agent's throughput depends on how quickly you notice its stop, and the unblocking is done by one person switching between windows.
So the real cost is the time between "agent stopped" and "human answered." That gap has three parts:
- Noticing. Knowing that a specific session is waiting.
- Finding context. Getting back the information needed to answer: what the agent was doing, what the client document says, what you decided yesterday.
- Answering. Typing the reply, approving the command, or handing over a new task.
Terminal sprawl makes all three worse at once.
What does each waiting agent actually cost you?
Idle agents waiting for permission. The most common stop is a permission prompt: may I run this command, may I edit this file. They are a good safety default, and also where agents spend the most unnoticed time. A prompt in a background tab looks exactly like an agent that is still working. You only find out when you happen to click on it.
Context switching. Every move to another terminal costs a mental reload. Which project is this? Is this the session that handles auth, or the one fixing the tests? With panes, nothing stands out. With tabs, nothing is visible until you open it.
Questions lost in scrollback. Agents ask good questions, and they ask them in the middle of long output. "Should the export include archived orders?" is one line between two hundred lines of test results. If you don't answer now, it scrolls away, and later you either dig for it or the agent guesses. Scrollback is a log, not a to-do list.
Duplicated work. When the record of what each session is doing lives only in each terminal, there is no single place to see it. You start a new session to "fix the date parsing" without remembering that another session touched the same code an hour ago. The agents don't know about each other, and the only shared memory is you.
Why don't more tabs, panes or tmux fix it?
The usual response to sprawl is better terminal management: name your tabs, tile your panes, script a tmux layout per project. These are useful habits. But they solve a layout problem, and the bottleneck is a signal problem.
A tmux layout tells you where each session is. It doesn't tell you which one needs you. Named tabs help you find a project, but the tab title doesn't change when the agent inside stops to ask a question. Splitting the screen into nine panes makes everything visible, which in practice means nothing is noticeable.
Layouts also assume a fixed set of sessions, while agent sessions start for a task, finish and get replaced. Terminal tooling assumes you are the one typing. When agents do the typing, you need tooling that assumes you are the one being interrupted.
Claude Code itself has moved in this direction. Its Agent View (claude agents, a research preview) lists background sessions across projects and groups them by state, including Needs input, so you no longer need a terminal open per agent. That fixes the noticing step for Claude Code sessions. Finding the context and answering still depend on where your requests, plans and documents live.
For concrete habits, see how to manage multiple Claude Code sessions without losing context. For Agent View, tmux + git worktrees, Conductor and PMDesk side by side, see Choosing a setup for multiple Claude Code agents.
What actually fixes terminal sprawl?
Four things, roughly in order of impact.
A status signal for waiting agents. The single most useful change is making "this agent is waiting for you" visible without opening the session. It should show at the session level, roll up to the project, and ideally reach you when you are in another app. Once you have this, you stop polling tabs and start responding to events.
One place per project. Each project should have one home for its sessions, documents and open questions, so switching projects switches everything at once.
Requests and to-dos written outside scrollback. If a question or task matters beyond the current turn, it should live in a file, not in terminal output. Ask the agent to write it down, or write it yourself. A written request can be handed to a fresh session later with its context intact. A line in scrollback cannot.
A cap on concurrent sessions. Your attention has a fixed budget. Twelve sessions you can't keep up with are slower than five you can. A cap forces the useful question: is this new session worth more than finishing one that is already waiting?
You can approximate all four with notifications, a notes file per project and discipline. A tool helps when it makes them the default.
How does PMDesk approach it?
PMDesk is a macOS desktop app built around these four ideas, for people who direct AI coding agents across several projects.
- One tab per project. Each project gets a tab with Claude Code or Codex running in a real terminal. Sessions keep running in the background when you switch projects, and you can resume a session from history, rename it or archive it.
- A "Waiting" badge. When an agent finishes its turn or asks for permission, the session, the project tab and the sidebar show a Waiting badge. You can turn on a macOS notification as well, so you hear about it while you are in another app.
- Requests, change requests and to-dos as files. You write what you want done as a request and hand it to an agent in one click, which starts a new session. Later changes become change requests (CRs) linked to their own plan. To-dos let you, or the agent, park a question that should wait instead of leaving it in scrollback.
- A Tasks pane. On the Terminal page you can see the subagents Claude Code delegated to and the tasks of the plan the session is using. Tasks are ticked when a commit mentions them, which helps against the "two sessions doing the same thing" problem.
- Context in the same window. Client document folders (Box, Google Drive or any folder) can be registered and read in place; PMDesk never writes to them. You can reference files with @ in requests and comments, and review the Markdown or HTML an agent produces, comment on passages and send all fixes back at once.
Project data stays on your machine. PMDesk has no AI model of its own; the agent uses your own Claude Code or Codex subscription. PMDesk is an independent product, not affiliated with Anthropic or OpenAI.
Isn't the terminal still where the agent runs?
Yes, and that matters. Claude Code and Codex are terminal programs; their prompts, permission requests and slash commands are designed for a terminal. That is why PMDesk keeps the real terminal for every session, and you answer the agent there as you would in iTerm2 or Terminal.app.
What changes is everything around it: which session you look at next, where the context lives, and how many sessions run at once. The terminal stays where agents work. It stops being where you keep track of them.
If that matches how your week looks, you can download PMDesk for Mac and try it on the project with the most open tabs.
FAQ
What is the main bottleneck in agentic development?
Human attention. When agents write the code, each session regularly stops to wait for an answer or a permission. The time between the agent stopping and you noticing and answering is usually larger than the time the agent spends working.
How many Claude Code agents can one person manage at once?
There is no fixed number. It depends on how often each agent needs you and how fast you can find the context to answer. Past a handful of active sessions, agents tend to start sitting idle. An explicit cap helps you see that limit instead of hitting it by accident.
Does tmux solve the problem of too many terminals with Claude Code?
It helps with layout and with keeping sessions alive, but it does not tell you which session is waiting for you. tmux is a good foundation; the missing piece is a status signal and a place outside scrollback for questions and tasks.
Does Claude Code's Agent View solve terminal sprawl?
It solves a large part of it for Claude Code: background sessions run without a terminal each, and one list shows which ones need input. The context side remains: requests, plans, open questions and client documents still need a home outside scrollback.
What is an agent session manager?
A tool that runs and tracks several AI coding agent sessions, such as Claude Code or Codex, across projects. It shows which sessions are working and which are waiting, and lets you resume, rename or archive them.
Do I have to stop using my terminal to use PMDesk?
No. PMDesk runs Claude Code or Codex in a real terminal inside each project tab, so you interact with the agent the same way. It adds the waiting status, requests, to-dos and documents around that terminal.