[Bug]: Attention bell events for waiting sessions don't clear after clicking the row

[raphapizzi]

What happened?

When I click an attention event in the bell dropdown for a session that's in a "waiting" state (waitingForApproval or waitingForInput), the app correctly navigates me to the matching terminal tab — but the event stays in the bell list and keeps counting toward the unread badge. Only events of kind finished are cleared on click.

Expected: clicking a row should both navigate to the tab and mark the event as seen (remove it from the badge / list, like Slack/Discord/Gmail behavior). The session is still in its waiting state, but the notification purpose ("get the user's eyes on this tab") has been fulfilled.

Observed: click navigates correctly, badge count stays at the same number, the event is still listed in the dropdown.

Note: during the same investigation session I initially saw clicks not navigating at all, but in later attempts the redirect did work consistently. So this report is specifically about the "doesn't clear" behavior — happy to file the no-redirect case separately if it resurfaces.

A small bit of uncertainty I want to flag

I'm not 100% sure whether this is purely a UX gap in AttentionBellButton or whether something on the Claude Code side is contributing. While debugging this I noticed Claude Code can spawn subagents / parent–child sessions, and I briefly wondered if subagent sessionIds were being surfaced as separate attention events while the visible tab belongs to the parent. I couldn't reproduce that mismatch in the most recent test (the click did land on the correct tab), but I wanted to mention it in case you've seen it from another angle — could be worth keeping an eye on whether Claude subsessions ever create duplicate or orphaned bell entries.

Steps to reproduce

1. Start a Claude Code session in DPlex that reaches a waitingForApproval or waitingForInput state (e.g. a permission prompt).
2. Switch focus to a different tab so the session needs attention.
3. Open the bell dropdown — confirm the event is listed with a red badge count.
4. Click the row for the waiting session.
5. Result: the correct tab is focused, but the bell still shows the event and the badge count is unchanged.

Suggested fix (one line)

In src/renderer/src/components/attention/AttentionBellButton.tsx, the handleRowClick handler only acknowledges finished events:

const handleRowClick = (event: AttentionEvent): void => {
  focusSessionTab(event.sessionId, event.providerId)
  if (event.kind === 'finished') acknowledge(event.compositeId)
  setOpen(false)
}

Calling dismiss(event.compositeId) for the waiting kinds would resolve this:

const handleRowClick = (event: AttentionEvent): void => {
  focusSessionTab(event.sessionId, event.providerId)
  if (event.kind === 'finished') {
    acknowledge(event.compositeId)
  } else {
    dismiss(event.compositeId)
  }
  setOpen(false)
}

The existing dismiss flow in attentionService.ts already handles re-surfacing nicely: suppressedUntilTransition clears on the next status transition, and sweepIdle() provides the idle-too-long escalation safety net. So the event will come back on its own if the session genuinely needs attention again.

AI provider involved

Claude Code

DPlex version

0.13.0

Before submitting

• I searched existing issues and this is not a duplicate.
• I am running the latest released version (or noted the version above).

[Ron537]

Hey @raphapizzi , thanks for the really thorough write-up — the steps to repro, the suggested one-liner, and
even the note about Claude subagents were all super helpful.

Quick context on why it was originally built this way: the bell was deliberately split into
"row click = look at it" and "X button = dismiss it". The idea was that a waiting session is
still an ongoing state, not a one-shot notification, so glancing at the tab shouldn't
auto-silence the reminder. But honestly your Slack/Gmail analogy is strong — clicking the thing
is a perfectly reasonable signal of "I've seen it", and the existing dismiss() +
suppressedUntilTransition + sweepIdle() machinery you spotted already makes that totally safe
to do.

Rather than just flipping the behavior (which would surprise anyone who liked the old
separation), I went with a toggle:

• New setting attentionClickClearsWaiting under Settings → Notifications → Mark seen on click,
  off by default so nothing changes for existing users.
• An inline mode pill at the top of the bell dropdown ("View only" / "Mark seen on click")
  that shows the current mode and toggles it with one click — so you don't have to dig into
  Settings every time, and new users can discover it.
• When on, clicking a waitingForApproval / waitingForInput row navigates and calls dismiss().
  finished events still always acknowledge on click, same as before.
• The bell will re-surface the event on the next status transition, or via the idle-too-long
  escalation, exactly as you described.

On the subagent concern — I didn't reproduce it either, but worth noting for anyone who runs
into it later: events are keyed by composite (providerId, sessionId), and the bell row click
navigates via focusSessionTab(sessionId, providerId), so if a Claude subagent ever surfaced its
own session ID we'd get a separate bell entry rather than a duplicate. If you see orphans or
mismatches in the future please open a separate issue with the session IDs you observe and I'll
dig in.

Shipping in v0.15.0 (#60).

Thanks again for taking the time to file such a clear, well-investigated issue — it made this an easy one to act on. 🙏