[FEATURE] Desktop: notify differently for "waiting on a permission prompt" and "task finished"
What I do
I run about 30 Claude Code sessions in parallel, every day, for work. Not a hobby setup.
The problem
The desktop app sends one OS notification, when a session finishes a task:
"The desktop app sends an OS notification when a Code session finishes a task and you aren't currently viewing that session."
But a session stops for two different reasons, and they need different responses from me:
- It finished. I should review the result. This can wait 10 minutes.
- It is waiting on a permission prompt or a question. Nothing happens until I answer. Every minute here is lost time.
With one or two sessions the difference does not matter. With 30, case 2 is where almost all of my wasted time goes. A session that is blocked looks exactly like a session that is done, so I open the wrong one first.
What I would like
Two notification kinds, and let me turn them on separately:
waiting- fired onNotification(permission prompt or question)finished- fired onStop(turn ended, output unreviewed)
The CLI already emits both hook events, so the information exists. It is only the notification layer that merges them.
If a single setting is preferred, then "notify me only when a session is waiting on me" would already solve most of it.
Why I think this is worth it
The hooks are what make this distinguishable. Tools that read the terminal output cannot tell "blocked" from "still thinking" - both look like output stopped. The desktop app has the hooks, so it is one of the few places where the distinction is cheap.
Showing cached comments. Read the full discussion on GitHub ↗
3 Comments
This happens with fewer sessions too: you can’t tell a blocked session from a finished one without opening them.
For Claude Code CLI sessions on macOS, there’s a partial workaround: Lunavect, a free menu bar app I maintain. It has separate notification switches for approval needed, input needed and response ready. The session list also shows which session is blocked.
It doesn’t cover Desktop-only sessions or change Claude Desktop’s own notifications. https://github.com/lovach/Lunavect
Thanks. Your first line is a better framing than mine. I wrote this from a 30-session setup, which makes it easy to file as an edge case. It is not one: the two stop reasons need different responses at any number of sessions.
It also adds what this request needed most. Two tools, built separately, split the same way from the same two hook events.
NotificationandStopare enough on their own, so nothing has to be inferred. Only the notification layer merges them.Agreed. One thing to watch for when implementing this: Stop can fire while background tasks are still running (background_tasks isn't empty). The "finished" notification should wait until those tasks are done so it doesn't arrive too early