description

In headless CLI mode (screenpipe record), the first Cmd+C permanently breaks clipboard capture.

get_clipboard() hops onto the libdispatch main queue via dispatch_sync (introduced in c3598dc to fix the off-main NSPasteboard SIGSEGV). That's correct in the desktop app, where the main thread runs the runloop — but the CLI's main thread is #[tokio::main]'s block_on, so the main queue is never drained and the sync hop blocks forever. The clipboard worker hangs, no clipboard row is written, and clipboard-read-inflight is left behind — so on the next startup the dead-man switch promotes the stale marker to clipboard-disabled-after-crash and clipboard capture is silently disabled until the user manually deletes the file.

Fix: probe the main queue once per process (async no-op, 500ms timeout). Alive (desktop app) → keep the main-thread sync_once read, unchanged. Dead (headless CLI) → read the pasteboard on the worker thread. This re-exposes the off-main race from 1Password/arboard#218, but it's the only option without a main runloop, the window is microseconds per read, and the existing crash-marker dead-man switch backstops a crash loop. If the queue is dead, the leaked probe block is harmless (it could only run at process exit).

related issue: none filed — happy to open one if preferred.

before

$ screenpipe record --disable-audio --disable-vision --data-dir /tmp/sp-test
# press Cmd+C with any text selected …

$ ls /tmp/sp-test/clipboard*
/tmp/sp-test/clipboard-read-inflight          # never cleaned up — worker hung
$ sqlite3 /tmp/sp-test/db.sqlite "SELECT count(*) FROM ui_events WHERE event_type='clipboard'"
0                                              # no clipboard row ever written

Sampled stack of the hung worker (100% of 1589 samples over 2s):

Thread: clipboard-capture
  _dispatch_sync_f_slow
    __DISPATCH_WAIT_FOR_QUEUE__
      _dispatch_thread_main_event_wait_slow   ← waiting for main thread to drain main queue
        __ulock_wait

Main thread at the same time: pthread_cond_wait inside tokio's block_on — never touches the dispatch main queue. On the next launch, the stale inflight marker is promoted to clipboard-disabled-after-crash → clipboard permanently off.

after

$ screenpipe record --disable-audio --disable-vision --data-dir /tmp/sp-test
# log on first Cmd+C:
INFO screenpipe_a11y::platform::macos: main dispatch queue not serviced (headless CLI) — clipboard reads will run on the capture worker thread, guarded by the crash marker

$ sqlite3 /tmp/sp-test/db.sqlite "SELECT text_content FROM ui_events WHERE event_type='clipboard'"
CLIP-PATCH-VERIFY-67890                        # payload captured
$ ls /tmp/sp-test/clipboard*
zsh: no matches found                          # inflight marker cleaned up

Desktop app path unaffected: the probe succeeds there, so reads stay on the main thread exactly as today.

how to test

1. cargo build --release --bin screenpipe, then ./target/release/screenpipe record --disable-audio --disable-vision --data-dir /tmp/sp-test --port 3042
2. Copy any text (Cmd+C), wait ~2s
3. sqlite3 /tmp/sp-test/db.sqlite "SELECT text_content FROM ui_events WHERE event_type='clipboard'" → shows the copied text (before this patch: zero rows, and /tmp/sp-test/clipboard-read-inflight is left behind)
4. Desktop app regression check: copy/paste with the app running — behavior unchanged (probe succeeds → main-thread read)

test status

cargo test -p screenpipe-a11y --lib: 166 passed, 3 failed — the 3 failures (test_get_clipboard_{set_and_read,unicode,large_content}) are pre-existing and fail identically on unpatched main (verified: 3 passed / 3 failed, same None assertion, baseline at f62ba66). They round-trip the real pasteboard from the test process, which doesn't work in a headless test environment on recent macOS — unrelated to this change.

🤖 Generated with Claude Code