777genius/claude-notifications-go

Environment: plugin v1.40.1 (commit 74b9fba), Fedora 44, GNOME Shell 50.4 on Wayland, click-to-focus daemon path. Symptom: in GNOME's notification list (calendar dropdown), plugin notifications collapse into one grouped source showing effectively icon-only entries — the rich per-event titles/bodies ("✅ Task Completed [session, project]") aren't visible until the group is manually expanded. Users read this as "notifications have no description". Cause: the daemon path sends a constant identity on every call — AppName: "claude-notifications" (internal/daemon/server.go, handleNotification()), plus the same fixed desktop-entry hint — so GNOME Shell groups everything under one source. Notably, the beeep fallback path already avoids exactly this: it randomizes AppName per call, with the comment "Use unique AppName to prevent notification grouping/replacement, allowing multiple notifications to be displayed simultaneously" (internal/notifier/notifier.go). The daemon path — the one t

Environment: plugin v1.40.1 (commit 74b9fba), Fedora 44, GNOME Shell 50.4 on Wayland, click-to-focus daemon active and healthy. Symptom: every notification shows the generic utilities-terminal stock glyph instead of the bundled Claude icon, even with notifications.desktop.appIcon set (default ${CLAUDE_PLUGIN_ROOT}/claude_icon.png, file present). Cause (two halves): The configured appIcon never reaches the Linux daemon path. SendDesktop() resolves and validates it (internal/notifier/notifier.go), but sendViaDaemon(title, body, cwd) has no icon parameter (internal/notifier/terminal_linux.go:52-71), and the daemon's handleNotification() builds the notify.Notification with no icon field at all (internal/daemon/server.go:262-274). The icon is only used by the beeep fallback — dead code whenever the daemon is healthy, i.e. in normal operation. With no icon in the D-Bus call, GNOME resolves identity via the desktop-entry hint, which on GNOME/Wayland always points at the hidden claude-notif

Follow-up to #113/#114/#115, same setup (macOS Tahoe, Ghostty 1.3.1, ~12 concurrent Claude Code sessions, most sharing one cwd). Two related findings from a week of running a locally patched build, with the fix we've verified in production. 1. The focus chain silently degrades to "wrong tab" instead of "no-op" focusGhosttyWindowWithOptions tries exact terminal-ID focus, then falls back to cwd matching, then to window-level AXDocument + activateByPID. Every step down that ladder loses precision: A stale terminal ID (session resumed via claude --resume, or a handed-off session) fails the ID step, then cwd matching can't disambiguate shared-cwd tabs, and the AXDocument fallback raises an arbitrary same-cwd window. A headless session (cron/CI, or a session living on another machine) has no tab at all — the click still activates the app and lands on whatever tab is frontmost. From the user's perspective both cases are "the notification lied to me": the click confidently focused a tab th

Summary MaybeCaptureGhosttyTerminalID (internal/notifier/ghostty_session_darwin.go) requires the frontmost terminal's name to contain "claude": lowerName := strings.ToLower(strings.TrimSpace(info.Name)) if !strings.Contains(lowerName, "claude") { return false } In practice Claude Code sets topic-based terminal titles (e.g. ✳ Plan comprehensive 5-7 day trip to Madeira Portugal) shortly after a session starts, so the "claude" substring almost never matches. Result: terminal IDs are captured only in a brief window right after session start (while the title is still generic "Claude Code") — for long-running sessions the ID is effectively never captured, and clicks depend entirely on the cwd fallback. This matters most in the common power-user setup where several Claude Code sessions run in tabs sharing the same project directory: without captured IDs, the cwd fallback cannot disambiguate them (see companion issue on that fallback). Evidence (debug log, v1.40.0) Ghostty terminal cap

Summary On macOS Tahoe (Darwin 25.x), Ghostty exact-tab click-to-focus never works and always falls back to AXDocument window-level focus, because ClaudeNotifier.app ships without NSAppleEventsUsageDescription in its Info.plist. macOS silently denies Apple Events from app bundles that lack the usage-description key — no Automation prompt is ever shown, and (until the key is added) no entry is even recorded in System Settings → Privacy & Security → Automation, so the user cannot grant the permission at all. This is the same class of problem as #47, but one layer deeper: #47 moved regular terminals off -execute osascript, while the Ghostty exact-tab path (added in v1.37.0 for #72) still runs osascript from the ClaudeNotifier context at click time — where TCC needs the plist key to attribute (and record) the request. Environment Plugin v1.40.0 macOS Tahoe (Darwin 25.4.0, arm64) Ghostty 1.3.1 (AppleScript dictionary available) Terminal ID present in session state (verified) — so