Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA 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.
Dictation bar indicator leaks duplicated voxtype status --follow processes
Reported by inyman · filed Aug 27, 2026 · open at source
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
Summary
The bar's Dictation indicator spawns a long-running voxtype status --follow --extended --format json process per bar surface and never reaps it, so processes accumulate per monitor and across hotplugs/reloads.
System
- Omarchy 4.0.1-1
- NVIDIA RTX 3070
- 4 monitors
What happened
On a fresh omarchy restart shell, ps shows multiple voxtype status --follow … processes (I saw 8 on a 4-monitor desk — one per bar-surface copy of the indicator). They're never terminated on rebuild; the count climbed over the session and grew further after disabling/re-enabling a monitor and config reloads.
Expected
One shared status process for the session (the vram-monitor service pattern), or a process terminated when its widget copy is destroyed.
Steps to reproduce
1. With multiple monitors, run omarchy restart shell.
2. ps -ef | grep voxtype | grep status — observe multiple copies.
3. Disable/re-enable a monitor or trigger a shell reload; the count increases.
Root cause (tentative)shell/plugins/bar/indicators/Dictation.qml declares a bare per-instance Process { running: true } instead of a shared service.
View raw text
**Summary**
The bar's Dictation indicator spawns a long-running `voxtype status --follow --extended --format json` process per bar surface and never reaps it, so processes accumulate per monitor and across hotplugs/reloads.
**System**
- Omarchy 4.0.1-1
- NVIDIA RTX 3070
- 4 monitors
**What happened**
On a fresh `omarchy restart shell`, `ps` shows multiple `voxtype status --follow …` processes (I saw 8 on a 4-monitor desk — one per bar-surface copy of the indicator). They're never terminated on rebuild; the count climbed over the session and grew further after disabling/re-enabling a monitor and config reloads.
**Expected**
One shared status process for the session (the `vram-monitor` service pattern), or a process terminated when its widget copy is destroyed.
**Steps to reproduce**
1. With multiple monitors, run `omarchy restart shell`.
2. `ps -ef | grep voxtype | grep status` — observe multiple copies.
3. Disable/re-enable a monitor or trigger a shell reload; the count increases.
**Root cause (tentative)**
`shell/plugins/bar/indicators/Dictation.qml` declares a bare per-instance `Process { running: true }` instead of a shared service.
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
Not linked to any known issue, other report or change yet.
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 09:40 UTC