**Omarchy version:** 4.0.3-1
**gpu-screen-recorder:** 6.1.0-1
**GPU/CPU:** Intel Iris Plus Graphics 645, i5-8257U (thermally constrained laptop)
**Kernel:** 7.2.4-arch1-Watanare-T2-1-t2

**What happened**

Stopping a screen recording while the system was under load produced the toast *"Screen recording error — Recording process had to be force-killed. Video may be corrupted."* The resulting file is indeed truncated: the mp4 index reports `duration=286.8` while the last video packet's `pts_time` is `202.0` — roughly 85 s of footage past the last decodable frame is gone. A second recording shows the same signature (`duration=234.2`, last packet `188.0`).

**Expected behavior**

Stopping a recording should finalize the file no matter how slow the machine is — data loss should not be on a fixed timer.

**Root cause**

`bin/omarchy-capture-screenrecording`, `stop_screenrecording()`:

```bash
pkill -SIGINT -f "^gpu-screen-recorder"

local count=0
while pgrep -f "^gpu-screen-recorder" >/dev/null && ((count < 50)); do
  sleep 0.1
  count=$((count + 1))
done
# ... -> pkill -9 after a flat 5 seconds
```

`gpu-screen-recorder`'s SIGINT path has to flush the encoder and write the mp4 trailer. On a loaded or thermally throttled machine that can exceed 5 s — my fan curve log shows core temp at 84 °C sustained for >90 s during the recording, and a coding-agent workload was running alongside. The SIGKILL then lands mid-mux.

**Evidence this was the script's timeout, not a crash**

- `coredumpctl` shows no `gpu-screen-recorder` dumps — not a segfault.
- No kernel OOM-kill or `systemd-oomd` entries — not memory pressure.
- The truncated files decode cleanly up to the cut point and carry a valid index — consistent with SIGKILL mid-write.
- The notification text matches the `pkill -9` branch verbatim.

**Deterministic reproduction**

The 5 s guillotine can be triggered without needing a genuinely slow machine:

1. `omarchy screenrecord --fullscreen`
2. `pkill -STOP -f '^gpu-screen-recorder'` (simulates a stalled finalize — the process still matches `pgrep`)
3. `omarchy screenrecord --stop-recording`

Five seconds later the SIGKILL fires, the error toast appears, and the output file is truncated. (`pkill -CONT` cleanup needed for any surviving instance.)

**Possible directions** — happy to go with whatever the maintainers prefer:

- Simply raise the bound (15–30 s covers slow machines without changing the shape of the code)
- Make it configurable, e.g. `OMARCHY_SCREENRECORD_STOP_TIMEOUT`
- Notify "finalizing recording…" while waiting, so a longer wait doesn't read as broken
- Kill only after N seconds *without write progress* (e.g. output mtime stalled), rather than a flat deadline

**Related:** the stale-bar-indicator side effect of this same force-kill path is tracked in #9205 — see my comment there for a script-side ordering issue that is distinct from the QML watchdog fixed in #9296.