Feature request — automatic notifications when an agent pauses for user input or completes a long-running flow

[quocnm102]

Motivation

When an agent session stops and waits for the user (e.g. asking a question, waiting for approval, or surfacing a subagent failure), there is currently no built-in way to notify the user outside the Web UI. The user has to keep the tab open and watch for state changes, which defeats the purpose of long-running / background agent flows.

The runtime already exposes a rich SessionEventMap (approval/asked, tool/call, assistant/message, subagent/descriptor, etc.) and ships a notify tool with many channels (Telegram, Slack, Discord, webhook, desktop bell, …). What is missing is the automatic bridge between "agent entered a waiting/completed state" and "user gets notified on their preferred channel".

Proposal

Add a core-level notification layer that fires automatically on well-defined agent-state transitions, with two complementary surfaces:

1. Auto-notify (opt-in per channel, off by default)

When the agent enters one of the states below, DSH sends a notification through every channel the user has configured (respecting per-channel opt-in / quiet-hours if those settings exist):

Trigger	Suggested event name	Payload (minimum)
Agent calls ask_user_question and pauses for a reply	user/question-asked	session id, question text / options summary
Agent hits an approval gate (sandbox escalation, out-of-scope write, …) and waits for approve/reject	approval/asked (already exists)	session id, tool name, reason
A subagent fails / blocks / escalates and needs user intervention	subagent/escalated	session id, subagent id, failure reason
A long-running task or flow completes successfully	task/completed	session id, task/flow identifier, summary

Auto-notify should be off by default (to avoid surprise noise) and enabled per-channel via settings. When enabled, it uses the same delivery path as the existing notify tool so channel configuration is reused.

2. Open event / hook for plugins and presets

In addition to the built-in auto-notify, expose the same state transitions as first-class events on SessionEventMap (or an equivalent public surface) so that:

• Custom presets can subscribe and implement their own notification logic (e.g. aggregate multiple questions into one digest, route different triggers to different channels, apply custom throttling).
• Third-party plugins can integrate with external systems (ticket trackers, dashboards, mobile apps) without forking core.

The existing approval/asked event is a good template; the new events (user/question-asked, subagent/escalated, task/completed) should follow the same shape and lifecycle guarantees.

Why this belongs in core

• The state transitions are defined by core (only core knows when ask_user_question pauses the turn, when an approval gate blocks, when a subagent escalates). A plugin cannot reliably detect these without a core event.
• The notification delivery stack already lives in core (notify tool + channel registry). Auto-notify reuses it rather than duplicating channel logic in every preset/plugin.
• This matches the existing architecture: core owns state + events + delivery; presets/plugins subscribe and customize.

Non-goals / boundaries

• Not a replacement for the notify tool. Agents should still be able to send ad-hoc notifications explicitly; auto-notify only covers the "agent is waiting / done" cases users most often miss.
• Not opinionated about channel choice. Core provides the trigger + delivery hook; which channels fire is a user setting.
• Not synchronous. Notifications are best-effort, fire-and-forget; they must never block the agent's state machine or delay the turn.

Open questions for the team

1. Is there already an internal mechanism that tracks "agent is waiting for user" that could be surfaced as an event, or does this need new instrumentation?
2. Should auto-notify respect a global quiet-hours / do-not-disturb setting, or is that left to each channel plugin?
3. For task/completed, what counts as a "long-running" task worth notifying about? A configurable duration threshold, an explicit tag from the agent, or every terminal state change?

[Rigel772]

Great idea! No one interested?

[Windsland52]

+1 — and the reason every trigger you list gets reimplemented by plugins instead of subscribed to is precisely the missing seam.

Data points from the shipped build (0.2.0-rc.1):

• No core attention surface. None of the dsh-client-* bundles use the Notification API at all (new Notification(, Notification.permission, requestPermission: zero hits), and the only visibility read is unrelated (attachment echo paint timing). So every plugin hand-rolls its own visibility gate, title flash and host-level fallback — there are now at least five independent notification plugins because of it (出一个任务完成通知功能 #7437, dsh-notify — 任务完成/待回复通知：页面开着弹网页通知，浏览器关掉由 Host 弹原生通知 #7190, DSH | dsh-herald 传令官 | 长任务不用盯着屏幕等了：审批·回复·后台任务完成，桌面通知自动弹出（浏览器关闭也送达） #6624, DSH | Attention Notifier | Sounds, toasts and taskbar digits when a task finishes or waits for your approval #9003, 🎵 dsh-task-complete-sound — know when your agent finished, even from another tab #8415, DSH | dsh-task-notify | 任务结束后提醒你 / Task completion notifications #8736, DeepSeek Harness 桌面通知插件 #1084, DSH通知提示音插件 · dsh-notify-bell · Semantic Notification Sounds #2566, DSH | DSH Notifications | Sound notifications for agent interactions #4646).
• The desktop shell already has the pattern. The one focus-gated attention path in its own code is the mandatory-update reminder (isFocused() → return, else flashFrame(true) + native Notification, cleared on focus). "Notify only when the user is not looking" is an established shape here, not a new mechanism.

On your open questions: #5411 is a concrete reference implementation of the web-side half — visibility-gated, one alert per interaction, settings-backed (notify.enabled), degrading to a title flash when permission is denied — worth reshaping rather than rewriting. On task/completed, I would not gate on a "long-running" threshold: the transition itself (running → idle while nobody is looking) is already precise, and a duration threshold mostly buys surprise silences.

[vasanthsreeram]

For the missing waiting-state bridge, I would test delivery independently from resolution: notify once for a specific pending question ID, keep that question pending when delivery fails or quiet hours suppress the alert, and clear it only when the host accepts its answer. Replayed events should stay quiet. An old notification opened after cancellation should show that the request is closed. Keep approval/asked and ordinary question input distinct; answering a question must not resolve a tool authorization.

Disclosure: I build JustCallMe, a hosted phone channel for a specific blocking agent question. If you want to try the away-from-Web-UI question path separately, I can help with your own-phone verification, scoped key and private dashboard skill. In a disposable Claude Code/Codex session, ask "SQLite or Postgres for dummy project alpha?" Let one request expire and check alpha stays pending; answer a fresh request and check the retrieved answer stays with that request and task. Early access has 20 free minutes, no card.

DeepSeek Harness pairing is unimplemented and untested. Its native approval controls stay with the host. Use a disposable environment and keep phones, codes, keys and real project data private.

[furkancak1r]

dsh-composer-plus does this as a plugin: while dsh is in the background (desktop app or a background browser tab) you get an OS notification when a turn finishes (first line of the reply), or when a chat really waits for you, i.e. an approval (tool name), a question, or a plan review. Clicking it opens that chat, and the Dock/taskbar badge counts the chats waiting for you. Requests that get answered automatically stay silent, and a notification is withdrawn once its request is answered. Tested on macOS.

Install: Settings → Plugins → Add plugin → dsh-composer-plus → Enable now (web profile: dsh plugin --profile web add dsh-composer-plus). Disclosure: I'm the author; it's an unofficial community plugin (MIT), and every feature can be switched off in Settings → Composer Plus. If it helps you, a ⭐ on https://github.com/furkancak1r/dsh-composer-plus is appreciated.

[murtazox04]

On open question 2, from having built this layer: I'd make quiet hours a property of the person, enforced once in core, not per channel plugin. A few reasons and edge cases that came up:

• Per-channel DND leaks through fallbacks. If Telegram is quiet but Slack isn't, a "try the next channel" fallback delivers at 3 am anyway. One check before any channel is picked avoids that.
• Check at send time, not when the event fires. Retries, a slow queue or a deferred delivery can all push a notification that was fine at 21:55 into the quiet window. Re-check right before handing it to the channel.
• Hold, don't drop, but key the hold to the request. Deliver when the window ends, and if the question or approval was answered or cancelled in the meantime, drop the held alert instead of sending a stale one (this fits nicely with notifying once per pending request ID, as suggested above).
• Decide what may break through. An approval that blocks a running agent is the one case people often want to wake them, and a task/completed almost never is. A per-trigger "may bypass quiet hours" flag is simpler than per-channel rules.
• Collapse bursts. Three subagents escalating overnight should produce one message at the end of the window ("3 sessions are waiting for you"), not three.
• Use the person's time zone and watch DST. On the night clocks go back, aware datetimes in the same zone compare by wall-clock time in Python, so convert to UTC before comparing "is the window over yet?".

Disclosure: I maintain Cue, an MIT, self-hosted service that does this as a separate layer (quiet hours, per-person caps, digests, approvals that expire). It could sit behind a webhook from these events, but the points above hold whether you use it or build it into core. I wrote up the time-related bugs here.