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.
omarchy capture text persists OCR'd screen text to clipboard history
Reported by Ashwinhegde19 · filed Oct 3, 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
omarchy capture text runs OCR over an arbitrary screen region and copies the result with a plain wl-copy, so it is persisted to ~/.local/state/omarchy/clipboard-history.json.
The sibling command omarchy capture qr copies with --sensitive, and its comment at bin/omarchy-capture-qr:30-34 names the reason: a decoded QR can be an otpauth:// 2FA URI or a Wi-Fi password. The clipboard history recorder already honours that flag:
shell/plugins/clipboard/capture.sh:15-17
if [[ ${CLIPBOARD_STATE:-} == "sensitive" ]] || grep -qx 'x-kde-passwordManagerHint' <<<"$types"; then
exit 0
fiOCR output is at least as likely to be sensitive — the user selects the region precisely because it contains text worth extracting, which in practice means passwords, 2FA codes, private messages, and tokens. Those currently persist indefinitely in history.
I checked every other wl-copy producer in the tree. The rest are either already marked (omarchy-capture-qr:35, omarchy-menu-emoji-insert:13) or carry non-secret content: tab URLs (retention is the documented intent per manual/23-browsers.md:23), replays of content already in history (omarchy-clipboard-paste-text, paste-file), a file:// URI of the user's own transcoded output (omarchy-transcode:128), and peer IPs/hostnames/gateway (shell/plugins/panels/tailscale, network). This is the only unmarked producer that handles likely-secret content.
View raw text
`omarchy capture text` runs OCR over an arbitrary screen region and copies the result with a plain `wl-copy`, so it is persisted to `~/.local/state/omarchy/clipboard-history.json`.
The sibling command `omarchy capture qr` copies with `--sensitive`, and its comment at `bin/omarchy-capture-qr:30-34` names the reason: a decoded QR can be an `otpauth://` 2FA URI or a Wi-Fi password. The clipboard history recorder already honours that flag:
`shell/plugins/clipboard/capture.sh:15-17`
```bash
if [[ ${CLIPBOARD_STATE:-} == "sensitive" ]] || grep -qx 'x-kde-passwordManagerHint' <<<"$types"; then
exit 0
fi
```
OCR output is at least as likely to be sensitive — the user selects the region precisely because it contains text worth extracting, which in practice means passwords, 2FA codes, private messages, and tokens. Those currently persist indefinitely in history.
I checked every other `wl-copy` producer in the tree. The rest are either already marked (`omarchy-capture-qr:35`, `omarchy-menu-emoji-insert:13`) or carry non-secret content: tab URLs (retention is the documented intent per `manual/23-browsers.md:23`), replays of content already in history (`omarchy-clipboard-paste-text`, `paste-file`), a `file://` URI of the user's own transcoded output (`omarchy-transcode:128`), and peer IPs/hostnames/gateway (`shell/plugins/panels/tailscale`, `network`). This is the only unmarked producer that handles likely-secret content.
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 21:00 UTC