### System details

Omarchy 4.0.2-1; Hyprland 0.56.2 (efb50993780079460b0cbed1363e2166a2de1d9f); Quickshell 0.3.1; AMD Ryzen 9 3900X; NVIDIA RTX 4080, driver 610.57.04. Wayland, `input.follow_mouse = 1`. The stock `omarchy.emojis` plugin was in use when reproduced.

### What's wrong?

Selecting an emoji with the mouse can transfer focus to an application underneath the picker, so the emoji never reaches the composer that opened it. This was reproducible with Blip's FloatingWindow tiled below another app, with a browser beside it. Multiple conversations were affected; it was not specific to one draft.

### Reproduction

1. Arrange multiple tiled app windows so that the centered emoji picker overlaps an app other than the intended text composer.
2. Focus the intended composer and type some text (no message needs to be sent).
3. Open the stock picker with Super+Ctrl+E.
4. Click an emoji with the mouse in the part of the picker over another app.

Expected: insert the emoji into the composer that opened the picker.

Observed: focus can land on the underlying app; the original composer receives no paste keystroke and no emoji. It should also not be possible for the paste to go to an unintended app.

### Confirmation and diagnosis

Temporary instrumentation in the real Blip composer recorded only focus, paste-key metadata, and paste-helper lifecycle—not message text. Failed mouse selections did not deliver Shift+Insert or start Blip's paste helper. Triggering insertion directly, and activating the picker programmatically without the mouse click, delivered Shift+Insert and completed the paste successfully.

The actual mouse-click path was then reproduced: the active toplevel after picker dismissal was the adjacent browser rather than Blip. Earlier isolated tests that omitted this focus transition passed and did not reproduce the bug.

In `shell/plugins/emojis/Emojis.qml`, `applySelected()` dismisses the picker and invokes `bin/omarchy-menu-emoji-insert` with only the emoji. That helper waits 150 ms and uses `wtype -M shift -k Insert -m shift`; it has no record of the originating window.

### Verified local fix

A local plugin override now:

- Captures `Hyprland.activeToplevel.address` when `open()` is called, before showing the picker.
- Passes that address to the insertion helper.
- Validates the address and checks that the original client still exists; if it closed, aborts without pasting elsewhere.
- Restores focus to that client and dispatches both Shift+Insert key events with an explicit `window = "address:<original-address>"` using `hl.dsp.send_key_state`.
- Retains the sensitive, transient clipboard behavior.

The patched mouse-click path inserted into the intended test composer, and the affected user confirmed that clicking emojis now works in the real Blip composer. Three isolated helper tests cover explicit targeting, closed targets and invalid addresses; they do not access the real clipboard or send messages.

This report is for an upstream fix; the workaround is currently a local cloned plugin. Packaged Omarchy files were not modified.

The documented `omarchy debug --no-sudo --print` command is unavailable in this build (`Unknown Omarchy command`), so verified component versions are included above. No screenshots of private conversations are attached.