Proof Portal

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-1733GitHub issuePublicReceived

Emoji not sent to clipboard

Reported by nightdevil00 · filed Aug 17, 2026 · open at source

In the audited area (menu) — decided by agents · verified. Not validated yet.

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?
Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. So far: in the audited area (menu) — decided by agents · verified. The outcome (valid, duplicate, not a bug, …) is not decided yet. See the decision.

Original report

Emoji not sent to clipboardrevision 1 · captured 2026-09-28 21:29 UTC via poll

System details

THinkbook 15p Quattro

What's wrong?

Fix: Emoji picker does not copy selected emoji to clipboard

Problem

Selecting an emoji from the emoji picker (Super+Ctrl+E) does not copy it to the
clipboard. The emoji is typed into the focused application via wtype, but it is
not available for subsequent paste operations (Ctrl+V).

Root cause

bin/omarchy-menu-emoji-insert runs wl-copy with --foreground and then
kills the process after a short delay. Killing the wl-copy process
disconnects it from the Wayland compositor, which clears the clipboard content.

wl-copy already forks by default to keep serving paste requests in the
background. The --foreground flag prevents that fork, and the kill at the
end terminates the only process holding the clipboard.

Fix

bin/omarchy-menu-emoji-insert

 #!/bin/bash
 
 # omarchy:summary=Insert an emoji into the focused application
 # omarchy:group=menu
 # omarchy:args=<emoji>
 # omarchy:hidden=true
 
 emoji="${1:-}"
-copy_pid=""
 
 [[ -n $emoji ]] || exit
 
-printf '%s' "$emoji" | wl-copy --type text/plain --sensitive --foreground &
-copy_pid=$!
+printf '%s' "$emoji" | wl-copy --type text/plain
 
 sleep 0.15
 wtype -M shift -k Insert -m shift 2>/dev/null || true
-sleep 0.2
-
-kill "$copy_pid" 2>/dev/null || true

Removed:

  • --sensitive — hinted the compositor to clear clipboard on client disconnect
  • --foreground — prevented wl-copy from forking to serve paste requests
  • & backgrounding, PID tracking, and kill — the kill disconnected

wl-copy from the compositor, clearing the clipboard

wl-copy without --foreground forks a child that keeps the clipboard alive
until something else replaces it. The parent exits immediately when stdin EOF
is received.

Testing

After applying the fix, open the emoji picker (Super+Ctrl+E), select an
emoji, then Ctrl+V into any application. The emoji should appear.

Also verify the clipboard still works after the script exits:

printf '%s' "😀" | wl-copy --type text/plain
sleep 0.5
wl-paste  # should print 😀
sleep 2
wl-paste  # should still print 😀
View raw text
### System details

THinkbook 15p Quattro 

### What's wrong?

# Fix: Emoji picker does not copy selected emoji to clipboard

## Problem

Selecting an emoji from the emoji picker (`Super+Ctrl+E`) does not copy it to the
clipboard. The emoji is typed into the focused application via `wtype`, but it is
not available for subsequent paste operations (`Ctrl+V`).

## Root cause

`bin/omarchy-menu-emoji-insert` runs `wl-copy` with `--foreground` and then
`kill`s the process after a short delay. Killing the `wl-copy` process
disconnects it from the Wayland compositor, which clears the clipboard content.

`wl-copy` already forks by default to keep serving paste requests in the
background. The `--foreground` flag prevents that fork, and the `kill` at the
end terminates the only process holding the clipboard.

## Fix

### `bin/omarchy-menu-emoji-insert`

```diff
 #!/bin/bash
 
 # omarchy:summary=Insert an emoji into the focused application
 # omarchy:group=menu
 # omarchy:args=<emoji>
 # omarchy:hidden=true
 
 emoji="${1:-}"
-copy_pid=""
 
 [[ -n $emoji ]] || exit
 
-printf '%s' "$emoji" | wl-copy --type text/plain --sensitive --foreground &
-copy_pid=$!
+printf '%s' "$emoji" | wl-copy --type text/plain
 
 sleep 0.15
 wtype -M shift -k Insert -m shift 2>/dev/null || true
-sleep 0.2
-
-kill "$copy_pid" 2>/dev/null || true
```

Removed:

- `--sensitive` — hinted the compositor to clear clipboard on client disconnect
- `--foreground` — prevented `wl-copy` from forking to serve paste requests
- `&` backgrounding, PID tracking, and `kill` — the `kill` disconnected
  `wl-copy` from the compositor, clearing the clipboard

`wl-copy` without `--foreground` forks a child that keeps the clipboard alive
until something else replaces it. The parent exits immediately when stdin EOF
is received.

## Testing

After applying the fix, open the emoji picker (`Super+Ctrl+E`), select an
emoji, then `Ctrl+V` into any application. The emoji should appear.

Also verify the clipboard still works after the script exits:

```bash
printf '%s' "😀" | wl-copy --type text/plain
sleep 0.5
wl-paste  # should print 😀
sleep 2
wl-paste  # should still print 😀
```

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

Not linked to any known issue, other report or change yet.

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.

  • Decided by agents · verified: in the audited area (menu)

The outcome (valid, duplicate, not a bug, …) is not decided yet.