Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA 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.
Clipboard history: text entries that look like email or JSON cannot be pasted (wl-copy infers a non-text MIME type)
Reported by khalil-omer · filed Oct 7, 2026 · open at source
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?
- AreaOutside the audited area· 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
What happens
Selecting certain text entries in the clipboard history (Super+Ctrl+V, then Enter, Shift+Enter or click) closes the picker but pastes nothing. Other entries paste fine. It depends only on the content of the entry.
Cause
bin/omarchy-clipboard-paste-text copies the entry with an untyped wl-copy:
jq -j --argjson index "$history_index" '.[$index].text' "$history_path" | wl-copy
...
printf '%s' "$text" | wl-copyWithout --type, wl-copy infers the MIME type from the content (via xdg-mime query filetype). When the result is not text/*, it offers only that type, so no text/plain is available and the following Shift+Insert has nothing to paste. Text I have confirmed is detected as non-text:
| Content | Detected type |
|---|---|
Starts with From: … / To: … / Subject: … headers (e.g. an email copied as text) | message/rfc822 |
A JSON snippet such as {"a": 1, "b": [2, 3]} | application/json |
The watcher is also wl-paste --type text --watch, so the re-copied entry is no longer seen as text either.
Steps to reproduce
- Copy this text from any app:
From: [email protected]
To: [email protected]
Subject: hi
body- Copy something else, so the entry above is no longer the current clipboard.
- Open the clipboard history, select the
From: …entry, press Enter. - Nothing is pasted.
wl-paste -lshows onlymessage/rfc822.
Shell-only version of the same thing:
printf 'From: [email protected]\nTo: [email protected]\nSubject: hi\n\nbody\n' | wl-copy
wl-paste -l # message/rfc822 — no text/plainExpected
A history entry of type text is always pasteable as text.
Suggested fix
History entries handled by this script are text by definition, so state the type on both calls, as omarchy-chromium-copy-url-host and omarchy-menu-emoji-insert already do:
- jq -j --argjson index "$history_index" '.[$index].text' "$history_path" | wl-copy
+ jq -j --argjson index "$history_index" '.[$index].text' "$history_path" | wl-copy --type text/plain
...
- printf '%s' "$text" | wl-copy
+ printf '%s' "$text" | wl-copy --type text/plainbin/omarchy-capture-text has the same untyped printf "%s" "$TEXT" | wl-copy and would fail the same way for OCR'd text that happens to look like one of these formats.
System
- Omarchy 4.0.4-1 (script is unchanged on
quattroas of 902fd8ae) - wl-clipboard 2.3.0
- Intel Core Ultra X7 358H, Intel Arc B390 (Panther Lake)
View raw text
## What happens
Selecting certain text entries in the clipboard history (Super+Ctrl+V, then Enter, Shift+Enter or click) closes the picker but pastes nothing. Other entries paste fine. It depends only on the content of the entry.
## Cause
`bin/omarchy-clipboard-paste-text` copies the entry with an untyped `wl-copy`:
```bash
jq -j --argjson index "$history_index" '.[$index].text' "$history_path" | wl-copy
...
printf '%s' "$text" | wl-copy
```
Without `--type`, `wl-copy` infers the MIME type from the content (via `xdg-mime query filetype`). When the result is not `text/*`, it offers *only* that type, so no `text/plain` is available and the following Shift+Insert has nothing to paste. Text I have confirmed is detected as non-text:
| Content | Detected type |
|---|---|
| Starts with `From: …` / `To: …` / `Subject: …` headers (e.g. an email copied as text) | `message/rfc822` |
| A JSON snippet such as `{"a": 1, "b": [2, 3]}` | `application/json` |
The watcher is also `wl-paste --type text --watch`, so the re-copied entry is no longer seen as text either.
## Steps to reproduce
1. Copy this text from any app:
```
From: [email protected]
To: [email protected]
Subject: hi
body
```
2. Copy something else, so the entry above is no longer the current clipboard.
3. Open the clipboard history, select the `From: …` entry, press Enter.
4. Nothing is pasted. `wl-paste -l` shows only `message/rfc822`.
Shell-only version of the same thing:
```bash
printf 'From: [email protected]\nTo: [email protected]\nSubject: hi\n\nbody\n' | wl-copy
wl-paste -l # message/rfc822 — no text/plain
```
## Expected
A history entry of type `text` is always pasteable as text.
## Suggested fix
History entries handled by this script are text by definition, so state the type on both calls, as `omarchy-chromium-copy-url-host` and `omarchy-menu-emoji-insert` already do:
```diff
- jq -j --argjson index "$history_index" '.[$index].text' "$history_path" | wl-copy
+ jq -j --argjson index "$history_index" '.[$index].text' "$history_path" | wl-copy --type text/plain
...
- printf '%s' "$text" | wl-copy
+ printf '%s' "$text" | wl-copy --type text/plain
```
`bin/omarchy-capture-text` has the same untyped `printf "%s" "$TEXT" | wl-copy` and would fail the same way for OCR'd text that happens to look like one of these formats.
## System
- Omarchy 4.0.4-1 (script is unchanged on `quattro` as of 902fd8ae)
- wl-clipboard 2.3.0
- Intel Core Ultra X7 358H, Intel Arc B390 (Panther Lake)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.
- Out of scopeDecided by agents · verified · 2026-10-09 22:30 UTC