The promise of background coding agents is that you kick off a task and go do something else. The reality, for a lot of people, is kicking off a task, doing something else, and coming back forty minutes later to find the agent stopped three minutes in, waiting for permission to run a command.
An agent that waits silently is worse than an agent that interrupts you, because the silence costs you the whole gap. Here is every practical way to get notified the moment a Claude Code agent needs your input.
Disclosure: I work on Blume, covered as one option below.
Option 1: Claude Code's agent view
Claude Code has a built-in answer for multiple sessions: agent view. It shows what every session is doing and which ones need input, lets you dispatch new sessions, and while it is open, the terminal tab title shows a count of sessions awaiting input.
Crucially, agent view also sends notifications through your configured terminal notification channel when a background session starts needing input, finishes, or fails. This uses the same preferredNotifChannel setting as the rest of Claude Code, so make sure that is set to something you will actually notice (terminal_bell or your OS notifier).
Good for: running several Claude Code sessions from one terminal.
The gap: you need agent view open, and it covers Claude Code only.
Option 2: The Notification hook
For full control, Claude Code fires a Notification hook event with types like agent_needs_input and agent_completed. A hook is a shell command, so you can route it anywhere: macOS notification, Slack webhook, ntfy push to your phone.
A minimal macOS example in .claude/settings.json:
{
"hooks": {
"Notification": [
{
"hooks": [
{
"type": "command",
"command": "osascript -e 'display notification \"Claude needs input\" with title \"Claude Code\" sound name \"Glass\"'"
}
]
}
]
}
}
Swap the osascript for a curl to a Slack webhook or ntfy.sh topic and the alert follows you off the machine.
Good for: people who want alerts in a specific channel, deterministically.
The gap: per-machine setup, and it alerts without showing state. You still open the terminal to see what the agent wants.
Option 3: Stay current on permission-prompt fixes
One reason this problem feels worse than it should: for a while, background subagents could be silently blocked by permission prompts that never surfaced, which looked like a hung agent. Since v2.1.186, background subagents surface their permission prompts into the main session, labeled with the subagent's name, and you approve with a keypress.
If agents seem to hang with no prompt anywhere, update Claude Code before debugging anything else. Several apparent hangs in older versions were exactly this bug.
Option 4: A desktop dashboard across all your agents
The options above are per-tool and per-terminal. Blume approaches it from the desktop: it monitors your coding agents across Claude Code, Codex, and Cursor and shows at a glance which are running, which are working, and which are stuck waiting for approval, without you cycling through terminal tabs. Because it also tracks plan usage, "why did my agent stop" has one more answer visible in the same place: sometimes the agent is not waiting for permission, it is waiting for your 5-hour window to reset.
Blume's broader premise is that interruptions like these are often symptoms of setup problems. An agent that constantly asks for permission usually has a permissions config that does not match how you actually work, and Blume's suggestion engine flags exactly that kind of mismatch (along with rules your agents ignore and hooks that never fire) and proposes fixes you approve or reject.
Good for: multi-agent, multi-project setups.
The gap: if you run one agent in one terminal, the built-ins above are probably enough.
Reduce the prompts instead of just routing them
The best notification is the one that never fires. Three habits shrink the number of approval stops dramatically:
-
Pre-approve what you always approve. If you say yes to
npm testevery time, put it in your allowlist in.claude/settings.json. Every rubber-stamp prompt is pure interruption - Scope permissions per project. A prototype repo can run permissive; a production repo should not. Checked-in project settings mean the whole team gets the same behavior
- Audit what the agent actually asks for. The prompts you keep approving are a to-do list for your permissions config. This is the kind of setup-versus-behavior mismatch that tooling can watch for you
FAQ
Do I get notifications when Claude Code runs in the background?
Yes, if agent view is open or you configure the Notification hook. Otherwise a stopped background session waits silently, which is the trap this post exists to fix.
Can I get alerts on my phone?
Yes. Point the Notification hook at a push service like ntfy.sh or a Slack webhook.
Why does my agent stop even though I approved everything?
Check three things in order: an unsurfaced permission prompt (update Claude Code), a hit usage limit (/usage), or the agent finished and the completion notification went nowhere.
If you have a notification setup that survives real use, especially for a fleet of parallel agents, share it in the comments.
Top comments (1)
Approval signals are underrated. A good agent workflow should not require staring at the terminal; it should surface the moments where judgment is actually needed: destructive actions, uncertain evidence, scope changes, and external effects.