Desktop notification sound plays repeatedly upon opening and can't be dismissed #15302

Activity

1. itsjling

   added

   bugSomething isn't workingSomething isn't working

   on Feb 27, 2026
2. github-actions

   assigned

   iamdavidhill

   on Feb 27, 2026
3. github-actions

   added

   webRelates to opencode on web / desktopRelates to opencode on web / desktop

   on Feb 27, 2026
4. johanohly commented on Apr 8, 2026

   

   johanohly

   on Apr 8, 2026

   More actions

   I have the exact same issue, also on macOS 26.3.
5. thdxr

   removed

   bugSomething isn't workingSomething isn't working

   webRelates to opencode on web / desktopRelates to opencode on web / desktop

   on May 3, 2026
6. Ahmet-Dedeler commented on Jun 1, 2026

   

   Ahmet-Dedeler

   on Jun 1, 2026

   More actions

   Did some digging into this on 1.15.13 (macOS, Apple Silicon) and I'm fairly confident I found the root cause. It's the "error" notification sound being replayed from the event backlog on every connect, not an unread/notification-dot sound.

   Root cause

   The desktop app is event-sourced. On launch the Electron client connects to the local sidecar server and subscribes to the event stream, and the server replies with a backlog of every event since the client's last-seen sequence (compactBacklog({ remoteEntries: entriesAfter(journal, startSequence) })), concatenated ahead of the live subscription:

   const backlog = yield* compactBacklog({
     remoteEntries: entriesAfter(ensureJournal(storeId), startSequence),
     compactors
   });
   return Stream.fromArray(backlog).pipe(Stream.concat(Stream.fromSubscription(subscription)...))

   That backlog includes historical session.error events, and they run through the same handler as live events — there's no "this is a replay, stay quiet" guard:

   const handleSessionError = (directory, event, time) => {
     void lookup(directory, sessionID).then((session) => {
       if (session?.parentID) return;
       if (settings.sounds.errorsEnabled()) {
         void playSoundById(settings.sounds.errors());   // default: "nope-03"
       }
       ...

   So every session that previously ended in an error re-fires session.error on connect → plays the nope error sound. With a few dozen errored sessions in the journal (aborted runs, APIError, ProviderAuthError, etc.), you get a rapid burst of the failure sound for ~10-15s until the backlog drains. It "can't be dismissed" because clearing the red dots doesn't change the journal — the same backlog replays on the next connect (and on the iPhone web view, which is just another client doing the same backlog sync).

   The same path applies to settings.sounds.agentEnabled (turn-complete / staplebops-01) and settings.sounds.permissionsEnabled, all of which default to true — errors are just the most noticeable because failed sessions accumulate.

   Suggested fix

   Suppress notification sounds (and OS notifications) for backlog/replayed events — only play them for events arriving on the live subscription. e.g. tag backlog entries and gate the playSoundById(...) / platform.notify(...) calls in handleSessionError / handleSessionIdle / the permission handler on !isReplay. The events should still be appended to the notification list; they just shouldn't (re-)alert audibly.

   Workaround for anyone hitting this now

   Settings → General → Sounds → "Errors" → Off (flips errorsEnabled to false). Turn off "Agent"/"Permissions" there too if you want full silence. Doesn't fix the underlying replay, but stops the noise.

   ❤️React with ❤️2Reacted by exoJSON and Evgenii Tereshkov
7. exoJSON commented on Jun 18, 2026

   

   exoJSON

   on Jun 18, 2026

   More actions

   Yes, this is still a very annoying and active bug. It makes the app feel broken, even though it isn't.

   Thank you @Ahmet-Dedeler, that's a good workaround for now.

   I would suggest adding date metadata to the notification sender. That way it could send only fresh/not-previously-announced errors and notifications.

   I don't see much point in receiving a barrage of sounds/notifications. It becomes noise and nothing useful comes of it.
8. github-actions commented on Aug 18, 2026

   

   github-actionsBot

   on Aug 18, 2026 – with GitHub Actions

   Contributor

   More actions

   To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
9. github-actions

   closed this as not plannedon Aug 18, 2026