desktop: "needs attention" (question-pending) never produces a system notification #59779

Activity

1. opencodejr commented on Oct 28, 2026

   

   opencodejrBot

   on Oct 28, 2026

   More actions

   Thanks for the clear report. I couldn't reproduce this here, because it needs the desktop app with real system notifications and this sandbox can't run it. A maintainer with the desktop app will need to confirm it.

   The code supports what you describe. The app's notification handler (in both v2.1.4 and the current dev branch) only sends system notifications when a session finishes or fails. Nothing handles the event for a question waiting on your answer, so with the window unfocused you get no notification for it.

   Related:

   • fix(app): fix permission and question alerts #56044: an open PR that adds notifications for both permission requests and questions, which would likely cover this
   • desktop: "needs permission" system notification never fires although setting is enabled (completion notifications work) #51507: the same missing notification for permission requests
   • Feature request: play a sound when the agent asks a question (question.asked) #49371: request for a sound when the agent asks a question
2. shashb27 commented on Oct 28, 2026

   

   shashb27

   on Oct 28, 2026

   More actions

   In my case this was happening in the TUI — question tool called mid-stream, no prompt visible, session just sitting there until I interrupted (#43196). Finding it took a while because my first two hypotheses were wrong: Solid store reactivity (disproved with a unit test — the store was fine) and SSE drops mid-stream (the event was never emitted at all). What actually nailed it was per-hook tracing in plugin.trigger plus a counter showing Question.ask never ran: a plugin of mine had a tool.execute.before hook awaiting a blocking macOS notification binary (alerter — it doesn't exit until you dismiss the notification), so the question tool body never executed and question.asked never fired. Every event-keyed path downstream stayed silent because the event itself never happened. #41847 and #36604 looked like the same family on the permission side.

   My fix attempt then was defense-in-depth recovery polling — tool part running but the question store empty → poll question.list/permission.list until the prompt appears (#43300, closed unmerged). In v2 the visibility side got properly fixed and I haven't hit it since. The thing I took away anyway: "needs attention" is safer derived from state than from events, because the event is exactly the part that goes missing when something else is wrong. The CLI's noninteractive runner still works the state way — it fetches session.form.list and permission.list to decide what's pending rather than trusting the stream.

   #56044 looks like it covers the main path here, including the child-session case routed to the root tab. Curious whether the cold-start/reconnect case — a question already pending before the app attaches, or an event missed on a reconnect — is worth covering too, and whether that belongs in this PR or a follow-up. If a state-derived sweep ever happens, the one wrinkle I'd flag from the subagent side is that it can't just iterate open tabs — subagent sessions never get tabs of their own, so it'd need to walk the session tree, which is the same session.root machinery this PR already uses for routing. Happy to brainstorm.

   And one caution from my round of this for the plugin ecosystem: fire-and-forget any dismissal-gated notification inside a tool hook, never await it — otherwise the question ends up blocked on its own notification.
3. EpycZen commented on Oct 29, 2026

   

   EpycZen

   on Oct 29, 2026

   More actions

   Yes this is important! questions stop the workflow, the least it should do is give us a notification
4. usrnk1

   closed this as completedin #60358on Oct 29, 2026