`omarchy-install-and-launch` ends by prompting for a keystroke in the presentation
terminal while simultaneously launching the app it just installed. The new window
takes keyboard focus, so the keystroke the prompt invites is delivered to that
window instead of to the terminal.

## What happens

`omarchy-install-and-launch` backgrounds the launch and then falls through to the
presentation wrapper's completion prompt:

```bash
# omarchy-install-and-launch
exec omarchy-launch-floating-terminal-with-presentation \
  "echo ${install_message}; omarchy-pkg-add ${packages} && (setsid uwsm-app -- gtk-launch ${desktop_id_arg} >/dev/null 2>&1 &)"

# omarchy-launch-floating-terminal-with-presentation
presentation_script="omarchy-show-logo; $cmd; if (( \$? != 130 )); then omarchy-show-done; fi"

# omarchy-show-done
gum spin --spinner "globe" --title "Done! Press any key to close..." -- bash -c 'read -n 1 -s'
```

`gtk-launch` is backgrounded, so `omarchy-show-done` runs immediately — displaying
"Done! Press any key to close..." during exactly the window in which the launched
app maps and grabs focus.

## Expected

The keystroke closes the presentation terminal — or the terminal doesn't ask for a
keystroke it is about to lose focus for.

## Steps to reproduce

1. Omarchy menu → Install → Gaming → Minecraft (any entry using
   `omarchy-install-and-launch` should do).
2. Let the install finish. The terminal shows "Done! Press any key to close..."
   and the app window appears at the same moment.
3. Press a key to dismiss the terminal.
4. The keystroke lands in the new app window. The terminal stays open until a
   second keypress.

Timing-dependent: it needs the app to map its window before you press a key. A
slow-starting app may let the keystroke reach the terminal instead.

## Evidence from a real occurrence

Journal, one install of `minecraft-launcher`:

```
20:10:03.887  xdg-terminal-exec scope started (org.omarchy.terminal, presentation)
20:10:10.238  gtk-launch minecraft-launcher scope started  (install finished; show-done now blocking on read)
20:10:10.310  launcher process starts, maps its GTK3 window
20:10:12.6    launcher scope ends (2.358s)
20:10:15.95   presentation terminal scope ends (12.044s)
```

The terminal was alive and blocked in `omarchy-show-done` from ~20:10:10 to
20:10:15.9. During that window a Return keypress went to the app instead: a core
dump of the launcher taken at 20:10:12 contains the delivered event —

```
GdkEventKey { type = GDK_KEY_RELEASE, keyval = 65293 /* Return */, hardware_keycode = 36 }
  gtk_main_do_event → gtk_window_propagate_key_event → gtk_button_key_release
  → gtk_button_finish_activate → gtk_button_clicked   (button label: "Cancel")
```

Under Wayland, key events are delivered only to the focused surface, so this is
direct evidence that the app window held keyboard focus while the terminal was
asking for a key. The terminal then closed at 20:10:15.9 on a second keypress.

## Note on the crash

In this instance the misdirected Return activated the focused "Cancel" button in
Mojang's bootstrapper, which segfaulted (SIGSEGV, call through a NULL vtable slot
— its `clicked` handler reads a third argument the two-argument `clicked` signal
never passes). **That crash is a bug in Mojang's proprietary binary, not in
Omarchy**, and is only included here to show how the misdirected keystroke
surfaced. The Omarchy-side issue is the focus race itself, which is independent of
which app gets launched.

## Possible directions

Either drop the "press any key" prompt when the presentation command ends by
launching a GUI app (the app appearing is its own completion signal), or launch
the app only after `omarchy-show-done` returns.

## Related but distinct

- #7174 — installer terminal vs. launched window, but that is a *stacking* problem
  (tiled browser buried under the floating terminal, which keeps focus). Here the
  launched window takes focus instead.
- #7870 — same `omarchy-install-*` family, but a missing `setsid`.
  `omarchy-install-and-launch` already uses `setsid`.

## System

```
Omarchy:   4.0.0-1 (stable)
Kernel:    7.1.8-arch1-3
Hyprland:  0.56.2
gtk3:      1:3.24.52-1
glib2:     2.88.3-1
foot:      1.27.0-2
```

(Correction to an earlier version of this report: `omarchy debug --no-sudo --print`,
which the reporting docs reference, *does* ship in 4.0.0 — it is just not reachable
through the dispatcher. `omarchy-debug` exists at `/usr/bin/omarchy-debug`, is tagged
`# omarchy:summary=Print debugging information`, and accepts exactly `--no-sudo` and
`--print`. But `omarchy` resolves subcommands only under `OMARCHY_BIN_DIR`
(`/usr/share/omarchy/bin`, set from the dispatcher's own location), where the file is
absent:

```bash
omarchy debug --no-sudo --print   # exit 127, "Unknown Omarchy command"
omarchy-debug --no-sudo --print   # exit 0, works
```

so `omarchy commands --all` does not list it either. `omarchy-debug-idle` and
`omarchy-upload-log` ship the same way — in `/usr/bin` only, both carrying
`omarchy:summary` tags. That looks like a separate bug and is not part of this report;
the system details above were collected manually.)

---
Filed by Claude Opus 5 via Claude Code.