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.
Shell reloads a local plugin on every write under it, including its own __pycache__ — reload storm freezes the shell
Reported by nocstah · filed Sep 15, 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
System details
Omarchy 4.0.3-1, Hyprland 0.56.2-2, quickshell 0.3.1-1, inotify-tools 4.25.9.0-1, python 3.14.7-1. MacBook Pro (T2) with Intel i9-8950HK, AMD Radeon Pro 560-series dGPU, kernel linux-t2 7.2.4.arch1-2.
What's wrong?
The shell's local plugin watcher reloads a plugin on any file write under ~/.config/omarchy/plugins/<id>/, including files the plugin's own helper processes write at runtime. A plugin with a Python helper hits this on every fresh import: CPython writes __pycache__/*.cpython-314.pyc, inotify reports create/close_write/move, the shell reloads the plugin, the reload restarts the helper, the helper imports the next lazily loaded module and writes the next .pyc, and so on. Each reload re-instantiates the plugin on all outputs, so a handful of bytecode writes turns into dozens of reloads and hundreds of spawned subprocesses.
Observed with the third-party plugin b.everything (brianblakely/omarchy-everything, whose helper is python3 helper/everything_helper.py) on a three-monitor setup. Journal excerpt, 20 reloads inside one second, each one matching a .pyc mtime to the millisecond:
17:51:13.304 Local plugin changed, reloading: b.everything <- everything/__pycache__/atspi_runtime.cpython-314.pyc 17:51:13.303
17:51:13.351 Local plugin changed, reloading: b.everything <- everything/__pycache__/server.cpython-314.pyc 17:51:13.350
17:51:13.374 Local plugin changed, reloading: b.everything <- everything/__pycache__/discovery.cpython-314.pyc 17:51:13.374
17:51:13.459 Local plugin changed, reloading: b.everything <- everything/providers/__pycache__/base.cpython-314.pyc 17:51:13.458
... (16 more within 17:51:13, 4 more at 17:51:40)Result: the shell's GUI thread sat at ~95% CPU for over an hour, omarchy-shell shell ping timed out, the bars stopped repainting, and the shell process had ~100 defunct children (hyprctl, omarchy-network, fc-list, marketplace-catalog.sh, …) from the repeated widget re-instantiation. Killing and relaunching the shell was the only way out. It recurs after every omarchy plugin update of that plugin, because updated sources invalidate the cache.
Steps to reproduce:
1. Install a third-party plugin whose service runs a Python helper that imports modules from inside the plugin directory (e.g. omarchy plugin add https://github.com/brianblakely/omarchy-everything --enable).
2. find ~/.config/omarchy/plugins/b.everything -name __pycache__ -exec rm -rf {} + to force recompilation, then omarchy restart shell.
3. journalctl --user -t omarchy-shell -f | grep 'Local plugin changed' shows one reload per module imported.
Where it lives: shell/services/PluginRegistry.qml, localPluginWatcher runs inotifywait -m -r -e close_write,create,delete,move on the plugins dir and forwards every path straight to localPluginChanged with no path filtering and no debounce.
Suggested fix (either alone breaks the loop, both would be ideal):
- Ignore runtime artefacts in the watcher: __pycache__/, *.pyc, .git/, and editor temp files (*~, .*.swp, *.tmp). inotifywait --exclude '(/__pycache__/|\.pyc$|/\.git/)' would do it.
- Debounce localPluginChanged per plugin (a few hundred ms) so a burst of writes from one save or one compile produces one reload.
Workaround used here: pre-compiling the plugin (python3 -m compileall) while the shell is down, or setting PYTHONDONTWRITEBYTECODE=1 in the session environment. The plugin author has been asked separately to set sys.dont_write_bytecode in the helper.
Full omarchy-debug output available on request (nothing in it beyond the versions above is relevant).
View raw text
### System details
Omarchy 4.0.3-1, Hyprland 0.56.2-2, quickshell 0.3.1-1, inotify-tools 4.25.9.0-1, python 3.14.7-1. MacBook Pro (T2) with Intel i9-8950HK, AMD Radeon Pro 560-series dGPU, kernel linux-t2 7.2.4.arch1-2.
### What's wrong?
The shell's local plugin watcher reloads a plugin on **any** file write under `~/.config/omarchy/plugins/<id>/`, including files the plugin's own helper processes write at runtime. A plugin with a Python helper hits this on every fresh import: CPython writes `__pycache__/*.cpython-314.pyc`, inotify reports `create`/`close_write`/`move`, the shell reloads the plugin, the reload restarts the helper, the helper imports the next lazily loaded module and writes the next `.pyc`, and so on. Each reload re-instantiates the plugin on all outputs, so a handful of bytecode writes turns into dozens of reloads and hundreds of spawned subprocesses.
Observed with the third-party plugin `b.everything` (brianblakely/omarchy-everything, whose helper is `python3 helper/everything_helper.py`) on a three-monitor setup. Journal excerpt, 20 reloads inside one second, each one matching a `.pyc` mtime to the millisecond:
```
17:51:13.304 Local plugin changed, reloading: b.everything <- everything/__pycache__/atspi_runtime.cpython-314.pyc 17:51:13.303
17:51:13.351 Local plugin changed, reloading: b.everything <- everything/__pycache__/server.cpython-314.pyc 17:51:13.350
17:51:13.374 Local plugin changed, reloading: b.everything <- everything/__pycache__/discovery.cpython-314.pyc 17:51:13.374
17:51:13.459 Local plugin changed, reloading: b.everything <- everything/providers/__pycache__/base.cpython-314.pyc 17:51:13.458
... (16 more within 17:51:13, 4 more at 17:51:40)
```
Result: the shell's GUI thread sat at ~95% CPU for over an hour, `omarchy-shell shell ping` timed out, the bars stopped repainting, and the shell process had ~100 defunct children (`hyprctl`, `omarchy-network`, `fc-list`, `marketplace-catalog.sh`, …) from the repeated widget re-instantiation. Killing and relaunching the shell was the only way out. It recurs after every `omarchy plugin update` of that plugin, because updated sources invalidate the cache.
Steps to reproduce:
1. Install a third-party plugin whose service runs a Python helper that imports modules from inside the plugin directory (e.g. `omarchy plugin add https://github.com/brianblakely/omarchy-everything --enable`).
2. `find ~/.config/omarchy/plugins/b.everything -name __pycache__ -exec rm -rf {} +` to force recompilation, then `omarchy restart shell`.
3. `journalctl --user -t omarchy-shell -f | grep 'Local plugin changed'` shows one reload per module imported.
Where it lives: `shell/services/PluginRegistry.qml`, `localPluginWatcher` runs `inotifywait -m -r -e close_write,create,delete,move` on the plugins dir and forwards every path straight to `localPluginChanged` with no path filtering and no debounce.
Suggested fix (either alone breaks the loop, both would be ideal):
- Ignore runtime artefacts in the watcher: `__pycache__/`, `*.pyc`, `.git/`, and editor temp files (`*~`, `.*.swp`, `*.tmp`). `inotifywait --exclude '(/__pycache__/|\.pyc$|/\.git/)'` would do it.
- Debounce `localPluginChanged` per plugin (a few hundred ms) so a burst of writes from one save or one compile produces one reload.
Workaround used here: pre-compiling the plugin (`python3 -m compileall`) while the shell is down, or setting `PYTHONDONTWRITEBYTECODE=1` in the session environment. The plugin author has been asked separately to set `sys.dont_write_bytecode` in the helper.
Full `omarchy-debug` output available on request (nothing in it beyond the versions above is relevant).
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 13:42 UTC