niri-notify-focus — click a notification to jump to the exact source window

[Oaklight]

I often have multiple kitty terminals open across workspaces (several Claude Code sessions, etc.). When a notification pops up, clicking it has no way to take me to the specific window that sent it — I end up hunting through workspaces manually.

So I built niri-notify-focus, a lightweight daemon that solves this:

• Passively monitors D-Bus notification traffic via BecomeMonitor
• Maps each notification to its source window by tracking sender PIDs and walking the process tree
• On notification action click → focuses the exact window with a brief size pulse

Works with any app that sends desktop notifications (kitty, browsers, IDEs, etc.) and any notification daemon that emits ActionInvoked signals (mako, dunst, swaync, DMS).

Quick start (Arch)

paru -S niri-notify-focus
systemctl --user enable --now niri-notify-focus

Optional config

~/.config/niri-notify-focus/config.toml:

# "shrink" (default), "expand", or "none"
effect = "shrink"
pulse_pixels = 50

Zero config required — it works out of the box. Feedback and contributions welcome!

[bokicoder]

Both mako and swaync already implement xdg-activation, so they support focusing the notification sender window by clicking the notification.
Mako works perfectly on my desktop, so I suspect this is likely an issue on your desktop side.

• emersion/mako@6ac9242
• ErikReider/SwayNotificationCenter@49ff06a

[Sempyos]

There's does add a bit more features onto it

[Oaklight]

Thanks for the pointers! I'm aware that both mako and swaync emit an xdg-activation token when you click a notification — this works great for apps that already consume the token. However, it relies on two things:

1. The sending app listens for the ActivationToken D-Bus signal
2. The app then calls xdg_activation_v1.activate(token, surface) on its own Wayland surface

Today most desktop apps (kitty, Firefox/Chromium, many IDEs, etc.) don't implement step 1, so the focus hand-off stops at the app boundary. Even if they did, the token doesn't tell the app which of its multiple windows triggered the notification, so it may raise the wrong one.

niri-notify-focus tackles that gap: it watches the notification bus, traces sender PID → window via process tree walking, and asks niri to focus that exact surface. No app-side changes needed, and multi-window scenarios (e.g., five kitty terminals across workspaces) work reliably.

If you know of apps that already handle ActivationToken and pick the right window, I'd love to hear about them! In the meantime, I hope this clarifies why this daemon still has a role alongside xdg-activation.

[bokicoder]

If you know of apps that already handle ActivationToken and pick the right window, I'd love to hear about them!

Kitty! You keep bringing up Kitty, but it actually does support it.

Video_2026-05-02_18-27-13.mp4

[Oaklight]

You're right, I looked into kitty's source — it does handle ActivationToken since 0.36.0 and even tracks the originating pane internally. Fair point.

My use case goes a bit beyond kitty though. Most apps on my desktop (browsers, Electron stuff, various IDEs) don't implement the token handler at all, so for those, clicking a notification action just… does nothing focus-wise. niri-notify-focus is basically a catch-all for that — it works at the compositor level so individual apps don't need to opt in.

Kitty users on mako/swaync may not need it, but for a mixed desktop it's still useful.