A banner slides in: Claude Code wants permission to run the tests for the refund endpoint. You approve it and go back to the one file you meant to write yourself, while four other agents keep working. Then Codex, halfway through renaming a type in the shared package, wants to install a package. Another agent finishes. A fourth asks which of two approaches you prefer. By the third banner, the function you were writing has become a stranger.

Those banners are the defaults. Claude Code's hooks reference says its permission_prompt notification fires once a permission prompt "has waited about six seconds." Codex turns its terminal notifications on by default and fires them whenever the terminal is unfocused (sample config, config reference). Each agent is built to reach you fast.

My take: turn the per-agent pings off. Let blocked agents queue. Clear the queue at your own breakpoints, oldest first. An agent that waits ten minutes loses ten minutes of wall-clock time on one ticket. You lose more than that.

What the interruption research measured

In 2005, Gloria Mark, Victor González and Justin Harris at UC Irvine shadowed 24 information workers (managers, financial analysts and software developers) for over 700 hours of observation (CHI 2005 paper). People spent an average of 11 minutes 4 seconds in one working sphere before switching or being interrupted, and 57% of those spheres were interrupted. When interrupted work was resumed the same day, getting back to it took an average of 25 minutes 26 seconds, with a wide spread (standard deviation 54 minutes 48 seconds). In between, people worked on 2.26 other spheres on average.

The informants also said which interruptions hurt: the ones during work that needs concentration, the ones that come "when it is not a natural breaking point for a task," and the ones that drag you into a different working sphere. Five agents on five tickets are five different working spheres. A banner from any of them arrives on the agent's schedule.

Short interruptions cost something too. Erik Altmann, Gregory Trafton and David Hambrick gave people a task where they had to keep their place in a sequence of steps (Journal of Experimental Psychology: General, 2014). Interruptions averaging 2.8 seconds, "about the time to perform a step in the interrupted task," doubled the rate of sequence errors. Interruptions averaging 4.4 seconds tripled it.

You may not see the cost in your output, either. In a 2008 lab study, Mark, Daniela Gudith and Ulrich Klocke found that people finished interrupted tasks faster with no difference in quality, and paid with "more stress, higher frustration, time pressure and effort" (CHI 2008 paper).

None of these studies watched developers run coding agents. They watched people being pulled off a task, which is what a stream of agent banners does to you. Read the numbers as the shape of the cost, not as a measurement of yours.

A black silhouette of a developer at a desk with five small bells on strings ringing above them, each bell tugging the head in a different direction
Five agents, five bells, one head.

The agent can wait. Your train of thought can't

A blocked agent holds its place. The prompt stays on screen and the session and worktree are exactly where it left them. Come back in ten minutes and it continues from the same line. Its cost is wall-clock time on one ticket.

You hold your place in your head. When a banner pulls you out, the stack of half-made decisions about the function you were writing is what goes, and you rebuild it by hand. One of Mark's informants put it plainly: "I forget what I was testing and I might retest the same thing."

There's direct evidence that holding notifications until a breakpoint is cheap. Shamsi Iqbal and Brian Bailey built OASIS, a system whose scheduler "queues the request until the specified type of breakpoint occurs" in the user's task (CHI 2008 paper). Delivering notifications at breakpoints reduced frustration and reaction time compared with delivering them immediately. The price was a deferral of 1.5 minutes on average.

That's the trade on the table: a few minutes of agent latency against the context you're carrying. For most tickets, the agent should lose.

Turn the pings off, keep a log

Both big CLIs let you switch off their own alerts. Claude Code's terminal setup page says it sends a desktop notification by default in Ghostty, Kitty and iTerm2 (in iTerm2 once its alert settings are on). Its hooks reference lists notifications_disabled as a value of preferredNotifChannel, and says Notification hooks still run with it set. In ~/.claude/settings.json:

{ "preferredNotifChannel": "notifications_disabled" }

In Codex, tui.notifications takes a boolean or a list of event types. In ~/.codex/config.toml:

[tui] notifications = false

Turning the banners off doesn't mean losing track. A Claude Code Notification hook receives the event as JSON, with the message and the session's cwd. Point it at jq and each waiting agent becomes one line in a file instead of a banner:

{ "hooks": { "Notification": [ { "matcher": "permission_prompt", "hooks": [ { "type": "command", "command": "jq -c '[(now|todate),.cwd,.message]' >> ~/inbox.log" } ] } ] } }

Add a second entry with the idle_prompt matcher if you also want finished turns in the file. Per the hooks reference, it fires when Claude finished responding about 60 seconds ago and you haven't typed since. At a breakpoint, cat ~/inbox.log shows the waits in the order they arrived, oldest at the top.

This is only a log: a line stays there after you answer, and it only covers Claude Code.

Give the queue a consumer schedule

Once the agents queue, you're the consumer. The queueing math, why five agents don't make you five times faster, is in Five Parallel Coding Agents Won't Make You 5x Faster. You Are the Queue.

A single burnt-orange inbox tray on a desk holding a neat stack of five small terminal-window cards, with a calm black silhouette reaching for the bottom card
Pull from the queue when you reach a breakpoint, oldest card first.

  1. Pick your breakpoints in advance: after a commit, after a test run, before you start the next function. Check the queue there.
  2. Serve the oldest first. It keeps one agent from starving while you clear the easy questions.
  3. Answer, don't review. A permission prompt or a question takes seconds. Reading a finished diff is its own working sphere, so schedule it as one.
  4. Set a ceiling. My rule of thumb is to check at least every 25 minutes or so, so no agent sits blocked all morning.

Where Hermes IDE fits

I build Hermes IDE, so weigh this section with that in mind. It runs each agent in its own real terminal, on its own branch and worktree. Here the attention features are what matter. Every session shows one status: working, needs approval, asked you, done, error or idle, and it says when that status is a guess. The attention inbox counts the agents blocked on you, and ⌘I (Ctrl+Shift+I on Windows and Linux) jumps to the one that has waited longest.

You answer in the agent's own terminal. Hermes never answers a permission prompt for you and never types into a terminal on its own. Its system notifications fire when an agent is blocked on you or done, and never for the session you're already looking at. A notification is still a push, so the rule above holds: treat the inbox count as the thing you check at a breakpoint.

Two agent sessions side by side in Hermes IDE: Codex on orders-types and Claude Code on orders-api, each in its own hermes/ worktree, with the sessions sidebar on the left showing status, context use, cost and branch
Codex and Claude Code side by side, each in its own hermes/ worktree, with every session's status, context use, cost and branch in the sidebar.

Other tools cover part of this. Claude Code reports whether each session is working, waiting on you or done to terminals that implement the OSC 7501 status protocol, and its agent view shows the status of background sessions (terminal setup page). If you only run Claude Code, that may be all you need. Hermes is for when Claude Code, Codex and others share one screen.

Hermes is free, source-available under BSL 1.1, and runs on macOS, Windows and Linux; 2.3.4 is the current release. Download it or read the source on GitHub. It isn't affiliated with Nous Research, Anthropic, OpenAI or any agent vendor.

When to answer right away

Answer now when the agent is on your critical path: a hotfix, or a deploy a teammate is waiting on, where someone else is blocked behind the agent too.

Answer now when the question is about the code you're in. Mark's 2005 informants called interruptions inside their current working sphere helpful. The 2008 lab study found the context of an interruption made no difference to its cost, so don't lean on this exception too hard.

Everything else waits for a breakpoint.

How do you run yours: banners on for every agent, or a fixed time to check? Tell me in the comments.

If this was useful

A blocked agent in your inbox is a message on a queue, and you're the consumer deciding when to pull. Push or pull, how long a message may wait, what happens when a consumer falls behind: every event-driven system makes those calls. The Event-Driven Architecture Pocket Guide covers sagas, CQRS, the outbox and the traps around them, for when your queues carry orders instead of agents. If you run several agents on one repo, Hermes IDE is free to try.

Event-Driven Architecture Pocket Guide: Saga, CQRS, Outbox, and the Traps Nobody Warns You About