## System details

Omarchy `4.0.4-1` (quattro), Hyprland `0.56.2-2` (built from branch v0.56.2 at commit `efb5099378`), AMD Ryzen 7 8745HS / Radeon iGPU, single display `HDMI-A-1`.

## What's wrong?

Omarchy ships `misc.focus_on_activate = true`:

```
$ grep -n focus_on_activate /usr/share/omarchy/default/hypr/looknfeel.lua
109:    focus_on_activate = true,
```

Hyprland's own default for that option is `false`. Read back from the running compositor's option table rather than from the wiki:

```
$ hyprctl descriptions -j | jq -c '.[] | select(.name=="misc:focus_on_activate")'
{"name":"misc:focus_on_activate","description":"Whether Hyprland should focus an app that requests to be focused.","default":false,"current":false}

$ hyprctl getoption misc:focus_on_activate
{"option": "misc:focus_on_activate", "bool": true, "set": true }
```

`set: true` is the flag Omarchy's `hl.config({ misc = { focus_on_activate = true } })` sets — the same query on an option Omarchy does *not* touch (`misc:disable_autoreload`) returns `"set": false`. So this is a deliberate override of the upstream default, and the consequence is that **any** client that sends an `xdg-activation` request takes the keyboard and moves the active workspace to wherever that window lives, with no user input.

Two classes of victim:

1. **User-initiated, but jarring** — a running single-instance app is handed a URL from another process (clicking a link anywhere, `chromium <url>` from a terminal, `xdg-open`, a `mailto:` handler) and activates the window that owns the existing session, so the view jumps to whatever workspace that window happens to be on.
2. **Not user-initiated at all** — a background/automation-launched window, or a tray-resident app recreating its main window, yanks you out of whatever you were typing in. #7957 (`omarchy restart shell` reopens tray-resident Spotify and steals focus) is this same class, and it is the case that actually hurts: you are mid-keystroke in one window and the keyboard silently moves to another workspace because an app you did not touch asked for activation.

Measured here on 2026-10-03, before the local workaround (Chromium window on ws3, terminal focused on ws2):

```
$ hyprctl activeworkspace -j      # before -> "id": 2
$ chromium "https://example.com/"
正在现有的浏览器会话中打开。          # "opening in the existing browser session"
$ hyprctl activeworkspace -j      # after  -> "id": 3   <-- view jumped, no user input
```

## Steps to reproduce

1. `Super+3`, then `chromium &` — an empty Chromium window on workspace 3.
2. `Super+2`, focus a terminal.
3. Run `chromium https://example.com/` — it reports it is opening in the existing browser session and the active workspace moves to 3.
4. Background variant: leave a tray-resident app (the #7957 case) and run `omarchy restart shell` while typing somewhere else — the app's window comes back and takes focus.

## Why the default looks wrong

- Omarchy already treats app-initiated focus stealing as a bug and patches it app by app: `default/hypr/apps/telegram.lua` is exactly one line — `o.window("org.telegram.desktop", { focus_on_activate = false })`, commented "Prevent Telegram from stealing focus on new messages" — and #13688 proposes the same property for fullscreen windows. A global `true` with per-app opt-outs is the inverse of a safe default: every app nobody has written a rule for yet can move the user's view.
- The setting is doing double duty, and the second duty is what breaks: #7738 documents that with `focus_on_activate = false`, clicking a notification toast often does nothing, because the sender's default action fires an activation request, Hyprland denies it, and the class-match fallback never runs. So people who hate focus stealing turn the global setting off and then notifications feel broken. One flag is being used both to make notification clicks land *and* to hand every background process control of the active workspace.

## Proposed fix (either)

**a.** Default to `false` (drop the line) and stop depending on it for notification clicks. #7738 already contains the mechanism: Hyprland still emits `urgent>>ADDR` for the exact window that asked to activate, so the notification service can arm a short listener on click and focus that address, falling back to the class match otherwise. That click path is the only consumer that genuinely needs activation to be granted globally.

**b.** If `true` is deliberate, then ship the browser rule out of the box the way Telegram is handled —

```lua
o.window("((google-)?[cC]hrom(e|ium)|[bB]rave-browser|[mM]icrosoft-edge|Vivaldi-stable|helium|[fF]irefox|zen|librewolf)",
         { focus_on_activate = false })
```

— and document the tradeoff, so "opening a link from another app moves my workspace" is fixed for a stock install.

---

A one-line global default that lets any client — including unattended ones — move the user's view seems like the wrong trade for a distro that otherwise goes out of its way to keep the desktop quiet. Happy to attach `omarchy-debug` output or test a patch if useful.

*Disclosure: prepared with an AI coding agent (Hermes) at my direction, from measurements taken on my own machine; I reviewed the text and the quoted output.*