Stuck capture.sh silently stops text clipboard history (no timeout on wl-paste)

[mzijlstra-hia]

What happens

Text clipboard history silently stops recording. Image history keeps working, which makes it easy to miss — the clipboard manager still fills up, just with nothing you copied as text.

The cause is a capture.sh process that never exits:

$ ps -eo pid,ppid,etime,cmd | grep -E "wl-paste|capture\.sh"
   3495    2673  2-10:57:08 wl-paste --type text --watch .../clipboard/capture.sh text
   3497    2673  2-10:57:08 wl-paste --type image/png --watch .../clipboard/capture.sh image/png
 238185    3495  2-08:31:18 /bin/bash .../shell/plugins/clipboard/capture.sh text

238185 had been running for over two days. Because wl-paste --watch waits for its command to exit before handling the next clipboard event, the text watcher is blocked for as long as that process lives — so every subsequent text copy is dropped. The image watcher is a separate process and is unaffected, hence text-only loss.

Killing the stuck capture.sh restores text capture immediately; no restart of the shell or the watchers is needed.

Cause

shell/plugins/clipboard/capture.sh line 13 runs before the case dispatch, so it executes for every invocation including text:

types=$(wl-paste --list-types 2>/dev/null || true)

There is no timeout on it. wl-paste blocks indefinitely when the clipboard's owning client goes away mid-transfer, so a single bad copy wedges the script permanently.

The image path is already guarded against exactly this:

timeout 2s wl-paste --type "$mime" 2>/dev/null | emit_image "$mime"

but neither line 13 nor the final text read is:

wl-paste --type text --no-newline 2>/dev/null | emit_text

Suggested fix

Wrap the unguarded wl-paste calls the same way the image branch already does:

types=$(timeout 2s wl-paste --list-types 2>/dev/null || true)
...
timeout 2s wl-paste --type text --no-newline 2>/dev/null | emit_text

A capture that has not completed in two seconds is not going to complete.

Optionally, wl-paste --watch could be invoked with a wrapper that bounds total runtime, so a hang in any future code path degrades to a dropped entry rather than a dead watcher.

Steps to reproduce

Difficult to trigger deliberately, since it depends on a clipboard owner disappearing at the wrong moment. It has occurred twice here in ten days under normal desktop use. The failure is easy to confirm once present:

1. ps -eo pid,etimes,comm,args | grep capture.sh — a bash process running capture.sh with a large etimes
2. Copy text; nothing is added to ~/.local/state/omarchy/clipboard-history.json
3. Copy an image; it is added
4. kill -9 the stuck process — text capture resumes at once

System

• Omarchy 4.0.1-1
• Framework 13 AMD (Phoenix1, gfx1101), Hyprland
• shell/plugins/clipboard/capture.sh identical to current main at time of writing

[maxcroy1]

I reproduced both blocking paths deterministically against the current capture.sh using an isolated fake wl-paste. A 3-second stall in --list-types kept a watched-text callback blocked for the full 3.024 seconds even though its payload was already available on stdin; a 3-second stall in the snapshot --type text read similarly held capture for 3.013 seconds. The harness used temporary HOME/XDG paths and did not touch the live clipboard.

This confirms that capture lifetime currently follows an unresponsive wl-paste with no internal bound. I have not reproduced the intermittent real clipboard-owner disappearance race itself.

I am going to work on a narrow fix that bounds both reads and adds regression coverage in test/shell.d/clipboard-test.sh. I also checked open clipboard PRs #7422 and #7452; both touch capture.sh, but neither addresses these unbounded calls.