Desktop app badges unread count on transient API 529, even when the cycle succeeds

Status Open
Reported on v2.1.234
Maintainer reply None cached
Activity 0 comments · opened Aug 18, 2026

The Claude Desktop app (Linux, Electron) increments the taskbar/dock unread badge whenever a session's CCD CycleHealth check logs an unhealthy cycle with reason=api_error — including cases where the underlying API error was a transient 529 Overloaded that the app auto-retried and resolved (hadFirstResponse=true, final result still succeeds).

This means a badge fires for a server hiccup that self-healed, indistinguishable from a badge meaning "there's a message waiting for you." Since the badge is also the mechanism I rely on to know when Claude has said something worth checking, I can't disable notifications outright without losing that signal — but the false positives from transient 529 retries make the badge noisy.

Request: only increment the unread badge for cycles that need user attention (new completed response, pending permission request, genuine unresolved failure), not for a cycle marked "unhealthy" that nonetheless completed successfully after a retry.

Reproduction: hit a 529 Overloaded mid-conversation (server-side, not user-triggered) while the app window is unfocused. Log shows:

[warn] [CCD CycleHealth] <session> api_error (success): API Error: 529 Overloaded...
[info] [CCD CycleHealth] unhealthy cycle for <session> (...s, hadFirstResponse=true, reason=api_error)

Badge count increments even though the conversation's actual final response arrived fine.

Claude Code CLI version: 2.1.234, Claude Desktop 1.30096.1, Ubuntu 24.04.4.

View original on GitHub ↗