### System details

AMD Ryzen 7 9800X3D, NVIDIA RTX 5060 Ti (proprietary 610.43.03), Omarchy 4.0.0.r1373.g2e04f09-1 (`omarchy-dev` package, quattro at 2e04f09), Hyprland 0.56.0, foot 1.27.0, kernel 7.1.4-arch1-1.

I moved this machine onto quattro with DHH's dev upgrade script (`omarchy-upgrade-to-quattro --dev`), so it tracks the dev channel rather than being a stock quattro install. Happy to attach full `omarchy debug` output if useful — I've kept it out of the initial report rather than pasting a machine dump.

### What's wrong?

Universal copy (`SUPER + C`) **closes floating TUI windows instead of copying from them**, so there's no way to get text out of them with the Omarchy clipboard bindings.

#### Steps to reproduce

1. Open a TUI in a floating window — `CTRL + SHIFT + ESCAPE` (Activity / btop), About, or any menu entry that goes through the presentation wrapper such as `omarchy update`.
2. Press `SUPER + C`.
3. The window vanishes. Nothing reaches the clipboard.

#### Cause

`default/hypr/bindings/clipboard.lua:18-33` picks between the terminal chord (`CTRL+Insert`) and the GUI chord (`CTRL+C`) by matching the focused window's class against a fixed set:

```lua
local terminal_classes = {
  alacritty = true,
  ["com.mitchellh.ghostty"] = true,
  foot = true,
  kitty = true,
  wezterm = true,
}
```

Floating TUIs never carry one of those classes. `bin/omarchy-launch-tui` and `bin/omarchy-launch-floating-terminal-with-presentation` both pass `--app-id=org.omarchy.<command>`, so these windows map as `org.omarchy.btop`, `org.omarchy.terminal`, `org.omarchy.bash` — the very app-ids that `default/hypr/apps/system.lua:7` matches in order to tag them `+floating-window`.

So `active_window_is_terminal()` returns false for every one of them, `SUPER + C` sends a literal `CTRL+C`, the TUI takes it as SIGINT and exits, and the window closes.

`SUPER + V` shares the root cause and sends `CTRL+V` to these windows instead of `SHIFT+Insert`. Less visible, because most TUIs just ignore it.

#### Confirmation

Originally hit with a physical `SUPER + C`. To confirm the mechanism, with a floating `org.omarchy.btop` focused I dispatched exactly what the non-terminal branch dispatches:

```
$ hyprctl activewindow -j | jq -r '"\(.class) pid=\(.pid) floating=\(.floating)"'
org.omarchy.btop pid=1661674 floating=true

$ cat /proc/1661674/comm
foot

$ hyprctl dispatch 'hl.dsp.send_key_state({ mods = "CTRL", key = "C", state = "down" })'
$ hyprctl dispatch 'hl.dsp.send_key_state({ mods = "CTRL", key = "C", state = "up" })'

$ hyprctl clients -j | jq -r '[.[]|select(.class=="org.omarchy.btop")]|length'
0
```

Note the client process is `foot` — the window *is* a terminal, only its app-id doesn't say so.

#### Possible fix

Resolve terminal-ness from the client process rather than from the app-id. Every `org.omarchy.*` window is spawned through `xdg-terminal-exec`, so the window's pid is the terminal itself and `/proc/<pid>/comm` names it:

```lua
local terminal_processes = {
  alacritty = true,
  foot = true,
  footclient = true,
  ghostty = true,
  kitty = true,
  wezterm = true,
  ["wezterm-gui"] = true,
}

local function process_name(pid)
  if type(pid) ~= "number" or pid <= 0 then
    return nil
  end

  local comm = io.open("/proc/" .. pid .. "/comm", "r")
  if not comm then
    return nil
  end

  local name = comm:read("l")
  comm:close()

  return name
end

local function active_window_is_terminal()
  local window = hl.get_active_window()
  if not window then
    return false
  end

  local name = process_name(window.pid)
  if name and terminal_processes[name:lower()] then
    return true
  end

  -- existing class check kept as a fallback
  return window.class ~= nil and terminal_classes[window.class:lower()] == true
end
```

I've been running that as a local override in `~/.config/hypr/bindings.lua`. Verified with a real `SUPER + C` keypress (via `wtype`, so the Hyprland bind actually fires):

| Focused window | Before | After |
| --- | --- | --- |
| floating `org.omarchy.btop` | closes | survives |
| floating `org.omarchy.terminal` (presentation wrapper) | closes | survives |
| Brave (`comm=brave`) | `CTRL+C` | `CTRL+C`, unchanged |
| regular `foot` | `CTRL+Insert` | `CTRL+Insert`, unchanged |

Matching an `^org%.omarchy%.` class prefix instead would also fix it and avoids the `/proc` read, but it wouldn't cover the legacy `Omarchy` / `About` / `TUI.float` classes listed in that same window rule, nor a user's own custom app-id. Glad to open a PR for whichever direction you prefer.

#### Disclosure

The root cause and the proposed fix were found with AI assistance (Claude Code). The reproduction, the confirmation that it's the injected `CTRL+C` that closes the window, and the before/after verification were all executed against this live install rather than reasoned about.