> **Correction:** the claim below that Telegram registers no `"default"` action is wrong — it registers `["default","Open","mail-mark-read","Mark as read"]` and sends `desktop-entry = "org.telegram.desktop"`. That means the `if (!invoked)` guard, not the pattern matching, is what breaks Telegram in practice. Bus capture, corrected reproduction and fix in [this comment](https://github.com/basecamp/omarchy/issues/7369#issuecomment-5330578631).

### System details

Intel Core i7-14700KF, NVIDIA GeForce RTX 5060 Ti (GB206), Omarchy 4.0.0-1 (stable), Hyprland v0.56.2, quickshell-git 0.3.0.r20.g28771c7-1, telegram-desktop-bin 7.0.9-1, kernel 7.1.8-arch1-3

### What's wrong?

**Clicking a notification does nothing at all when the sender's `app_name` is not a substring of its window class.** Telegram is the common case: it notifies as `app_name = "Telegram Desktop"` while its window class is `org.telegram.desktop`.

Telegram registers no `"default"` libnotify action, so `invokePopupDefault()` in `plugins/notifications/Service.qml` takes the `if (!invoked) focusApp(entry)` fallback at line 394. `focusApp` passes `entry.app` as the **only** pattern to `omarchy-hyprland-focus-app`, which regex-matches it against window classes. `"Telegram Desktop"` never matches `org.telegram.desktop`, the helper exits 1, and its exit code is discarded — so the click is a silent no-op.

Measured against live windows on this machine:

| pattern passed to the helper | matches a window? |
|---|---|
| `Telegram Desktop` (what `focusApp` actually passes) | **no** — helper exits 1, click does nothing |
| `Telegram` | yes — `org.telegram.desktop` |
| `chromium` | yes — `chromium` |

So click-to-jump works only for apps whose display name happens to be a substring of their class (Chromium, Slack, Discord) and fails silently for any app with a space in its name or a reverse-DNS class.

A stronger identifier is already available but unused: **the freedesktop `desktop-entry` hint** carries the sender's application id, which for Wayland clients is normally the window class verbatim. `Service.qml` reads only the `transient` hint from `notification.hints` (line 151). The stored history entry also keeps `appIcon`, which for Telegram is `telegram` and *does* match the class.

### Steps to reproduce

1. Open Telegram Desktop and leave it on another workspace.
2. Simulate what it sends — a display name with a space and no actions:
   ```bash
   notify-send -a "Telegram Desktop" "CLICK-TEST" "Click me"
   ```
3. Click the toast.

**Expected:** focus moves to the Telegram window and its workspace.

**Actual:** nothing happens. Real Telegram messages behave identically.

Verified by watching the Hyprland event socket (`.socket2.sock`) across the click — no `activewindow>>` or `workspace>>` event is emitted at all. Note that polling `hyprctl activewindow` after the fact is unreliable here: ordinary user input steals focus back within a second or two and can make a *working* fix look broken.

### Suggested fix

Try several patterns, most precise first, instead of only the display name — and retry when the helper reports no match rather than discarding its exit code:

- `NotificationLogic.js` — read the hint and carry it on the snapshot (plus `POPUP_ROLES`, so it survives the persistence round-trip):
  ```js
  function desktopEntryFromHints(hints) {
    return stringHint(hints, "desktop-entry")
  }
  ```
  then build candidates, regex-escaped, most precise first: `desktop-entry`, `appIcon`, `app_name`, first word of `app_name`.
- `Service.qml` — have `focusApp` walk those candidates, advancing in `focusAppProc.onExited` whenever `exitCode !== 0`.

Confirmed working locally on a patched copy of the plugin. Trace from the identical code path a click takes (`invokePopupDefault(0)`):

```
candidates=["Telegram Desktop","Telegram"]
trying "Telegram Desktop" -> exited code=1
trying "Telegram"         -> exited code=0
Hyprland events: activewindow>>org.telegram.desktop + workspace>>9
```

### Relationship to #7260

#7260 reports the opposite failure of the same function: with several Chromium web apps open, `app_name = "Chromium"` matches *too much* and the plain browser window always wins. This report is the under-matching half — zero matches, so nothing happens.

The two fixes compose rather than conflict: a candidate list ordered most-precise-first is exactly where that issue's origin hint belongs (ahead of the app name), and preferring the `desktop-entry` hint also helps there, since Chromium web apps set it to the `chrome-<host>__-Default` app id. A single ordered-candidates mechanism in `focusApp` plus a retry-on-no-match in the helper would address both.

I can attach an `omarchy debug` log on request.