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-1207GitHub issuePublicDecided· Out of scope

Screen recording bar indicator gets stuck 'active' after a stopped/crashed recording

Reported by Kumpelo · filed Aug 30, 2026 · open at source

Decided: Out of scope — decided by agents · verified 4 days ago.

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

Screen recording bar indicator gets stuck 'active' after a stopped/crashed recordingrevision 1 · captured 2026-09-28 21:24 UTC via poll

Omarchy version: 4.0.1-1
GPU: NVIDIA GeForce RTX 4060

What happened

The screen recording indicator in the bar (ScreenRecording.qml) sometimes gets stuck showing "recording active" even though no gpu-screen-recorder process is running (verified with pgrep --quiet -f "^gpu-screen-recorder", which returns not-found). This happened repeatedly for me.

Expected behavior

The indicator should reflect the actual recording state at all times.

Likely cause

In refresh():

function refresh() {
  if (!root.bar || statusProc.running) return
  statusProc.command = ["pgrep", "--quiet", "-f", "^gpu-screen-recorder"]
  statusProc.running = true
}

If the previous Process's onExited never fires cleanly (e.g. the recording process terminated abruptly), statusProc.running appears to stay true forever. Since refresh() bails out early whenever statusProc.running is true, no further status checks ever run, and the icon stays frozen at its last known state.

Steps to reproduce

  1. Start a screen recording with omarchy screenrecord --fullscreen.
  2. Cause the underlying gpu-screen-recorder process to terminate abnormally (rather than via the normal stop flow) — e.g. kill it directly.
  3. Observe the bar indicator remains stuck showing "recording" indefinitely, even though no recording process exists.

Workaround

omarchy restart shell immediately resets the indicator to the correct state.

View raw text
**Omarchy version:** 4.0.1-1
**GPU:** NVIDIA GeForce RTX 4060

**What happened**

The screen recording indicator in the bar (`ScreenRecording.qml`) sometimes gets stuck showing "recording active" even though no `gpu-screen-recorder` process is running (verified with `pgrep --quiet -f "^gpu-screen-recorder"`, which returns not-found). This happened repeatedly for me.

**Expected behavior**

The indicator should reflect the actual recording state at all times.

**Likely cause**

In `refresh()`:

```qml
function refresh() {
  if (!root.bar || statusProc.running) return
  statusProc.command = ["pgrep", "--quiet", "-f", "^gpu-screen-recorder"]
  statusProc.running = true
}
```

If the previous `Process`'s `onExited` never fires cleanly (e.g. the recording process terminated abruptly), `statusProc.running` appears to stay `true` forever. Since `refresh()` bails out early whenever `statusProc.running` is true, no further status checks ever run, and the icon stays frozen at its last known state.

**Steps to reproduce**

1. Start a screen recording with `omarchy screenrecord --fullscreen`.
2. Cause the underlying `gpu-screen-recorder` process to terminate abnormally (rather than via the normal stop flow) — e.g. kill it directly.
3. Observe the bar indicator remains stuck showing "recording" indefinitely, even though no recording process exists.

**Workaround**

`omarchy restart shell` immediately resets the indicator to the correct state.

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

  • Related PRpr/10397· confirmed

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 10:09 UTC