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-290GitHub issuePublicDecided· Duplicate

Clipboard-owner timeout can stall omarchy-shell overlays

Reported by NeroSong · filed Sep 20, 2026 · open at source

Decided: Duplicate — decided by agents · verified 2 days ago.

R-1312 is the earliest report of this defect — filed Aug 28, 2026, open upstream. This report (filed Sep 20, 2026) describes the same defect, so it is folded under it in the inbox.

Decided by agents · verified· Oct 10, 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?
AreaPartly in the audited arealock· Decided by arbitration
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

Clipboard-owner timeout can stall omarchy-shell overlaysrevision 1 · captured 2026-09-28 21:23 UTC via poll

What happened

During a running desktop session, every Omarchy Shell overlay I opened, including the launcher and bar-plugin popups, visibly stalled for about one second before rendering.

The omarchy-shell journal contained repeated Qt Wayland clipboard-read timeouts during the affected interval:

QWaylandDataOffer: timeout reading from pipe
QWaylandDataOffer: error reading data for mimeType text/plain;charset=utf-8
QWaylandDataOffer: error reading data for mimeType text/plain

The session had no CPU, memory, or I/O pressure bottleneck. After the clipboard selection was replaced with ordinary plain text from another application, the Shell immediately returned to normal responsiveness.

At the time of the incident, the clipboard also advertised normal text formats plus these application-specific formats:

WeChat_RichEdit_Format
QQ_Unicode_RichEdit_Format
x-application-mimetype-xwechat

This is not intended as a WeChat-specific report: WeChat is only one observed selection owner. Any application that advertises a text format but stalls while serving it should not be able to make unrelated shell UI wait.

Expected behavior

Clipboard-history capture should fail closed for an unresponsive selection owner: discard that history item after a short bounded timeout while leaving the launcher, bar popups, notifications, and other omarchy-shell UI responsive.

The original clipboard selection should not be overwritten or coerced to plain text. Rich-text consumers should retain their normal clipboard behavior.

Observed recovery

Replacing the selection with ordinary plain text restored normal behavior immediately. A subsequent metadata-only wl-paste --list-types query completed in 3 ms and an omarchy-shell shell ping completed in 26 ms.

Suggested direction

Please consider making clipboard acquisition independent from the Shell UI path and bounded for every selection owner, rather than maintaining an application-specific MIME blacklist:

  1. Read only the requested plain-text representation for history.
  2. Enforce a short timeout and size bound in a worker/process that cannot block Quickshell UI.
  3. On timeout, malformed data, or worker failure, skip only that history entry.

A small standalone reproducer using a deliberately non-responsive Wayland data offer would be preferable to relying on a proprietary application. I do not yet have such a minimal reproducer, so this report documents the observed behavior and exact log evidence rather than claiming every rich-text application reproduces it.

Environment

  • Omarchy 4.0.4-1
  • Hyprland 0.56.2-2
  • Quickshell 0.3.1-1
  • wl-clipboard 1:2.3.0-1
  • Linux WeChat package 4.1.1.8-1 was the observed selection owner
View raw text
## What happened

During a running desktop session, every Omarchy Shell overlay I opened, including the launcher and bar-plugin popups, visibly stalled for about one second before rendering.

The omarchy-shell journal contained repeated Qt Wayland clipboard-read timeouts during the affected interval:

```text
QWaylandDataOffer: timeout reading from pipe
QWaylandDataOffer: error reading data for mimeType text/plain;charset=utf-8
QWaylandDataOffer: error reading data for mimeType text/plain
```

The session had no CPU, memory, or I/O pressure bottleneck. After the clipboard selection was replaced with ordinary plain text from another application, the Shell immediately returned to normal responsiveness.

At the time of the incident, the clipboard also advertised normal text formats plus these application-specific formats:

```text
WeChat_RichEdit_Format
QQ_Unicode_RichEdit_Format
x-application-mimetype-xwechat
```

This is not intended as a WeChat-specific report: WeChat is only one observed selection owner. Any application that advertises a text format but stalls while serving it should not be able to make unrelated shell UI wait.

## Expected behavior

Clipboard-history capture should fail closed for an unresponsive selection owner: discard that history item after a short bounded timeout while leaving the launcher, bar popups, notifications, and other omarchy-shell UI responsive.

The original clipboard selection should not be overwritten or coerced to plain text. Rich-text consumers should retain their normal clipboard behavior.

## Observed recovery

Replacing the selection with ordinary plain text restored normal behavior immediately. A subsequent metadata-only `wl-paste --list-types` query completed in 3 ms and an `omarchy-shell shell ping` completed in 26 ms.

## Suggested direction

Please consider making clipboard acquisition independent from the Shell UI path and bounded for every selection owner, rather than maintaining an application-specific MIME blacklist:

1. Read only the requested plain-text representation for history.
2. Enforce a short timeout and size bound in a worker/process that cannot block Quickshell UI.
3. On timeout, malformed data, or worker failure, skip only that history entry.

A small standalone reproducer using a deliberately non-responsive Wayland data offer would be preferable to relying on a proprietary application. I do not yet have such a minimal reproducer, so this report documents the observed behavior and exact log evidence rather than claiming every rich-text application reproduces it.

## Environment

- Omarchy 4.0.4-1
- Hyprland 0.56.2-2
- Quickshell 0.3.1-1
- wl-clipboard 1:2.3.0-1
- Linux WeChat package 4.1.1.8-1 was the observed selection owner

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-1312Decided by agents · verified · 2026-10-10 06:09 UTC