[FEATURE]: Desktop notification/error sounds should be configurable (mute, per-event control, custom sound) #41355
Description
Summary
The desktop app plays the OS error notification sound for every failure (model fetch timeouts, MCP connection drops, plugin load failures, etc.) with no way to mute, lower, or change it. On an unstable network this becomes a wall of beeps — the user cannot distinguish important errors from transient blips, and there is no settings entry to silence them.
Problem
- Every error event fires the system error sound (e.g. Windows "Exclamation") through the desktop shell.
- A single minute of network flakiness produces a rapid sequence of beeps with no persistence — you cannot "look back" at what beeped.
- No global mute, no per-event-type control, no volume, no option to choose a custom sound.
Proposal
Add a Sounds/Notifications section to desktop settings:
- Master toggle: mute all app sounds.
- Per-event-type controls (e.g. error / notification / success) — the user decides which events are audible.
- Optional custom sound file or OS default per event type.
- (Complementary) a small notification toast/log line alongside each sound so audible events are also visible — pairs with the Error Viewer discussion in Feature: centralized Error Viewer / diagnostics — startup error sounds are not discoverable in the UI #41194.
Use case
Working on a flaky connection: today every failed fetch triggers a beep; with per-event settings the user could mute errors while keeping success pings, or mute everything and rely on visual indicators from #41194.
Additional context
- Desktop app (Windows), latest version
- Related: Feature: centralized Error Viewer / diagnostics — startup error sounds are not discoverable in the UI #41194 (centralized error surfacing) — sounds are the audio half of that problem
Metadata
Metadata
Assignees
Labels
No labels
Activity
liudongyan13701205717-source commentedon Aug 15, 2026
Cross-link with #41194 (centralized Error Viewer) — error sounds are only useful if errors are surfaced; #41194 proposes the viewer. Both part of the "failures should be visible" theme. +1, would test on Windows Desktop.
liudongyan13701205717-source commentedon Oct 1, 2026
Coming back to this with a tighter version of the argument I made in the cross-link above, because it changes what "configurable" ought to mean here.
The case is not "let me pick a different WAV". It is that a notification you cannot address is worse than no notification. The repro recorded in #41194 is three startup beeps with zero ERROR lines in
opencode.logand nothing in the UI — so a user cannot answer the only two questions that matter: what failed, and was that three failures or the same failure three times. Until that is answerable, the practical options are to mute everything or to learn to ignore it, and both make the next real failure easier to miss. "Ignore the beep" is exactly the habit that makes #49726-style failures hard to report in the first place.So the ordering I would suggest: a visible error per event (#41194) plus a mute switch first, with custom sounds and per-event routing as a later layer. The mute switch is worth having on its own regardless — a startup failure you cannot silence during a call is its own problem — but it is a mitigation for an unaddressable signal rather than a fix for it.
Happy to test on Desktop.