Proof Portal

Sign in
Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.

Inbox
ReportR-963GitHub issuePublicFixed

Emoji picker does not insert selected emoji

Reported by AnoopLamba · filed Sep 4, 2026 · open at source

Open at source
Decided: Duplicate — decided by agents · verified 3 days ago.
Duplicate ofEmoji picker (SUPER+CTRL+E) fails to insert into browsers; works in terminals R-371

This defect is tracked under R-371. This report describes the same defect, so it is folded under it in the inbox.

Earliest report of this defect: R-963 (filed Sep 4, 2026).

Decided by agents · verified· Oct 9, 2026

At a glance

1 · What is claimed?
Only the report text below — no validator has restated it as checkable claims yet.
2 · What does it affect?
AreaIn the audited areamenu· Decided by agents · verified
3 · Is it reproducible?
No validation has been run yet.
4 · What remains unclear?
  • Not validated yet: no claims, no reproducer.
5 · What happens next?
Decided by agents and verified by a second, independent agent — see the decision.

Original report

Emoji picker does not insert selected emojirevision 1 · captured 2026-09-28 21:24 UTC via poll

System details

  • Omarchy: 4.0.2-1
  • Hyprland: 0.56.2
  • Kernel: 7.1.9-arch1-2
  • Session: Wayland / Hyprland
  • GPU: Intel Kaby Lake-R GT2 (UHD Graphics 620)
  • wl-clipboard: 2.3.0
  • wtype: 0.4
  • fcitx5: 5.1.21 (running)

What's wrong?

The built-in Omarchy emoji picker opens normally, but selecting an emoji does not insert anything into the focused text field. The picker closes after selection, but no emoji appears.

Steps to reproduce

  1. Focus any text input.
  2. Open the Omarchy emoji picker with Super+Ctrl+E.
  3. Click any emoji.
  4. Observe that the picker closes but the emoji is not inserted.

Expected behavior

The selected emoji should be inserted into the previously focused text input.

Investigation

The picker invokes omarchy-menu-emoji-insert, which currently does the following:

  • Copies the emoji with wl-copy --type text/plain ..., targeting the regular Wayland CLIPBOARD selection.
  • Sends Shift+Insert via wtype.

On Wayland/Linux, Shift+Insert uses the PRIMARY selection in common applications, not CLIPBOARD. This leaves the paste operation reading a different selection, so nothing is inserted. In the affected session, the regular clipboard and primary selection were also observed to contain different values.

The likely fix is either to copy with wl-copy --primary when using Shift+Insert, or to keep using the regular clipboard and send the equivalent regular-clipboard paste shortcut where appropriate.

This appears to be a reproducible issue in the packaged Omarchy implementation rather than a local configuration, font, or Fcitx issue.

View raw text
### System details

- Omarchy: 4.0.2-1
- Hyprland: 0.56.2
- Kernel: 7.1.9-arch1-2
- Session: Wayland / Hyprland
- GPU: Intel Kaby Lake-R GT2 (UHD Graphics 620)
- wl-clipboard: 2.3.0
- wtype: 0.4
- fcitx5: 5.1.21 (running)

### What's wrong?

The built-in Omarchy emoji picker opens normally, but selecting an emoji does not insert anything into the focused text field. The picker closes after selection, but no emoji appears.

### Steps to reproduce

1. Focus any text input.
2. Open the Omarchy emoji picker with `Super+Ctrl+E`.
3. Click any emoji.
4. Observe that the picker closes but the emoji is not inserted.

### Expected behavior

The selected emoji should be inserted into the previously focused text input.

### Investigation

The picker invokes `omarchy-menu-emoji-insert`, which currently does the following:

- Copies the emoji with `wl-copy --type text/plain ...`, targeting the regular Wayland `CLIPBOARD` selection.
- Sends `Shift+Insert` via `wtype`.

On Wayland/Linux, `Shift+Insert` uses the `PRIMARY` selection in common applications, not `CLIPBOARD`. This leaves the paste operation reading a different selection, so nothing is inserted. In the affected session, the regular clipboard and primary selection were also observed to contain different values.

The likely fix is either to copy with `wl-copy --primary` when using `Shift+Insert`, or to keep using the regular clipboard and send the equivalent regular-clipboard paste shortcut where appropriate.

This appears to be a reproducible issue in the packaged Omarchy implementation rather than a local configuration, font, or Fcitx issue.

Validation

Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.

Linked

Decision

Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.

  • DuplicateR-371Decided by agents · verified · 2026-10-09 10:08 UTC