Greptile Summary

This PR adds a response-completion sound cue with configurable volume, a Notifications section in the Control UI combining response cues and web-push controls, and fixes repeated push notifications being coalesced by assigning unique default tags. The implementation is clean and well-tested.

Two P2 concerns worth addressing before shipping:

• renotify: true is set unconditionally in sw.js: when the server provides an explicit data.tag for intentional coalescing, this will re-alert on every replace.
• AudioContext in playResponseCompletionSound is not resumed before scheduling notes; the context can start suspended with no recent user gesture, which is exactly the "hidden/unfocused" scenario the feature targets — leading to a silent failure.

Confidence Score: 4/5

Safe to merge; both findings are P2 and affect edge-case behaviour, not correctness of the main path.

Two P2 issues found (renotify coalescing edge case, AudioContext suspension). No P0/P1 defects. P2s alone cap at 4/5.

ui/public/sw.js (renotify unconditional), ui/src/ui/response-completion-cue.ts (AudioContext resume)

This is a comment left during a code review.
Path: ui/public/sw.js
Line: 94

Comment:
**`renotify: true` defeats intentional tag-based coalescing**

`renotify: true` is applied unconditionally, even when the server provides an explicit `data.tag`. If a future server-side notification uses a stable tag to intentionally coalesce repeated updates (e.g., a long-running job status), `renotify: true` will re-alert the user on every replace — the opposite of coalescing behaviour. The flag is only relevant when a notification replaces another with the same tag, so scoping it to the default-tag path avoids the conflict:

```suggestion
    tag: data.tag || `openclaw-notification-${Date.now()}`,
    renotify: data.renotify ?? !data.tag,
```

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: ui/src/ui/response-completion-cue.ts
Line: 82-115

Comment:
**AudioContext may be suspended — sound silently skipped**

`new AudioContextCtor()` can start in the `"suspended"` state when there is no recent user gesture. This scenario is exactly when the cue is most useful — the user has the tab hidden or unfocused. A suspended context still lets you call `currentTime` and schedule events, but they only play once the context is running; without `resume()` the scheduled oscillators are silently dropped.

Adding a `resume()` call before reading `currentTime` fixes this:

```ts
const context = new AudioContextCtor();
// Resume in case the context was created while the page had no recent gesture.
void context.resume().catch(() => undefined);
const now = context.currentTime;
```

Because `resume()` is async, schedule notes relative to `0` (or keep the `now` reference after the promise resolves) if tight timing is needed; for a short ding at 350 ms the 1–2 ms resume latency is imperceptible.

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "feat(ui): add notification controls" | Re-trigger Greptile}

Thanks for the context here. I swept through the related work, and this is now duplicate or superseded.

Keep this PR open: it still contains useful Control UI notification work that is not on current main, but it is not merge-ready because the head is dirty against main, browser-facing proof is still insufficient, and the new persisted UI settings/default notification behavior need maintainer review before landing.

Canonical path: Close this stale PR. The latest review rated it F, the branch still lacks merge-ready proof, and there has been no human follow-up after the durable review.

So I’m closing this here because the remaining work is already tracked in the canonical issue.

Addressed the two Greptile P2 findings in b374cec5:

• renotify now defaults to true only for generated fallback tags, preserving intentional server-provided tag coalescing unless explicitly overridden.
• response-completion audio now resumes a suspended AudioContext before reading currentTime and scheduling the cue.

Greptile’s visible summary still appears to reference the previous commit (d71c4d58), so it may be stale.

Re-review progress:

• State: Complete
• Detail: The targeted re-review finished, the durable review comment was updated, and the synced verdict was routed.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/25961316465
• Updated: 2026-05-16T12:03:47.265Z

Friendly bump 🙏 — would be great to see this land.

While waiting, I packaged the same idea as a zero-build local patch so users on main can have the cue today, and ship it via ClawHub:

• ClawHub: https://clawhub.com/skills/echo-cue ([email protected])
• Source: https://github.com/SymbolStar/echo-cue

It's intentionally narrower than this PR (no settings UI, no service-worker fixes — those still need to come from #73894 proper). My apply.sh actually checks for responseCompletionSound in the bundled JS and auto-skips itself the moment this PR (or anything equivalent) ships, so there's no coexistence trap.

Real-world feedback from running it locally for a few hours:

• Confirmed the state === "final" hook in handleTerminalChatEvent is the right anchor.
• NO_REPLY / silent completions need to be filtered (your PR already does this — important).
• Streaming long replies fired the cue multiple times until I added a hard rate-limit + content-fingerprint dedup; might be worth double-checking the same path here, especially with tool-heavy turns that re-render the assistant group.
• Default behaviour: I started with "only-when-hidden" but flipped it to "always ring" because foreground users found the cue useful as an end-of-turn marker too. Worth considering as the default value for responseCompletionOnlyWhenHidden.

Happy to help if there's review bandwidth — even a "needs changes" pointer would help unblock the lane. Cc @steipete who has been moving things along on adjacent Control UI lanes.

Thanks, this is really helpful, and appreciate you packaging a temporary workaround.

Good to know the final-state hook held up in real use. I will double-check the streaming and tool-heavy path for duplicate cue firing, and also think through whether the default should be always-on rather than hidden-only.

Glad the patch auto-skips once this lands. This PR is intended to be the proper upstream version with settings UI and push notification fixes included.

Pushed a follow-up in a34c722d based on the duplicate-cue feedback.

Changes:

• Pass the active run id and pre-final stream state into the completion cue path.
• Skip cues when the final produced no visible output.
• Skip silent stream-only finals like NO_REPLY even when there is no final message payload.
• Add a short dedupe window keyed by run id, with text fallback, so repeated terminal/re-render paths do not ring multiple times for the same completion.
• Added focused coverage for no-visible-output finals, silent stream-only finals, and duplicate run cues.

Verified locally:

• npm --prefix ui test -- response-completion-cue.node.test.ts app-gateway.node.test.ts
• 2 files passed, 53 tests passed.

This pull request has been automatically marked as stale due to inactivity.
Please add updates or it will be closed.

ClawSweeper applied the proposed close for this PR.

• Action: closed this PR.
• Close reason: duplicate or superseded.
• Evidence: durable ClawSweeper review.