Proof Portal

Sign in
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-1185GitHub issuePublicDecided· Out of scope

omarchy plugin add --enable: one-shot enablePlugin IPC times out ("omarchy-shell is not responding") while the shell is still rebuilding plugins; plugin lands installed but disabled

Reported by nocstah · filed Aug 31, 2026 · open at source

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

omarchy plugin add --enable: one-shot enablePlugin IPC times out ("omarchy-shell is not responding") while the shell is still rebuilding plugins; plugin lands installed but disabledrevision 1 · captured 2026-09-28 21:24 UTC via poll

What happened

omarchy plugin add <url> --enable --yes cloned and installed the plugin, then failed the enable half:

Cloning into '/home/noc/.config/omarchy/plugins/.add.tmp.948032'...
Added io.github.nocstah.omachill into /home/noc/.config/omarchy/plugins/io.github.nocstah.omachill
omarchy-shell is not responding

omarchy plugin list afterwards shows the plugin installed but disabled. Running omarchy plugin enable <id> a few seconds later succeeds every time.

Why (traced through the scripts)

  1. omarchy-plugin-add calls omarchy-shell shell rescanPlugins, then polls omarchy-plugin-list --json (IPC listPlugins) for up to 40 × 0.05 s until the id appears, then calls omarchy-plugin-enable exactly once.
  2. omarchy-plugin-enable runs omarchy-shell shell enablePlugin "$id" "$placement" — a single IPC call.
  3. omarchy-shell wraps every call in timeout 2s (ipc_timeout=${OMARCHY_SHELL_IPC_TIMEOUT:-2s}) and maps exit 124 to omarchy-shell is not responding (bin/omarchy-shell:59–63).
  4. After the rescan the shell is in finishPluginReload → Qt.clearComponentCache() → recreating every panel, service and bar widget synchronously (shell.qml). With enough installed plugins that stretch blocks the QML event loop for more than 2 s, so the discovery poll (answered during/right after scanning) succeeds while the one-shot enablePlugin call that follows it times out.

So the race is between the enable call and the shell's own plugin reconstruction that omarchy-plugin-add itself triggered one step earlier. The discovery loop is given patience; the enable call is not.

The same 2 s window can also bite a bare omarchy plugin enable/disable run immediately after any write under ~/.config/omarchy/plugins/ (the inotify watcher starts the same reload).

Reproduce

On a shell with many plugins installed (15 third-party here — the reload takes several seconds; a nearly stock install usually wins the race):

omarchy plugin add https://github.com/nocstah/omachill --enable --yes
# → "Added ..." then "omarchy-shell is not responding"; plugin left disabled
omarchy plugin enable io.github.nocstah.omachill   # succeeds

Reproduced twice on 2026-08-30 (17:11 +07 via plugin add --enable; also with a plain enable right after an rsync into the plugins dir). The shell was healthy throughout — omarchy-shell shell ping answers ok once the reload finishes.

Expected

Either the enable call gets the same patience the discovery poll already gets (retry on timeout for a few seconds), or enablePlugin is queued by the shell when it arrives mid-reload. Since omarchy-plugin-add knows it just triggered the reload, a bounded retry around step 2 seems like the smallest fix.

Environment

  • omarchy 4.0.1-1, quickshell 0.3.1-1, Hyprland 0.56.2 (Lua config), Arch
  • 15 third-party plugins installed under ~/.config/omarchy/plugins/
View raw text
## What happened

`omarchy plugin add <url> --enable --yes` cloned and installed the plugin, then failed the enable half:

```
Cloning into '/home/noc/.config/omarchy/plugins/.add.tmp.948032'...
Added io.github.nocstah.omachill into /home/noc/.config/omarchy/plugins/io.github.nocstah.omachill
omarchy-shell is not responding
```

`omarchy plugin list` afterwards shows the plugin **installed but disabled**. Running `omarchy plugin enable <id>` a few seconds later succeeds every time.

## Why (traced through the scripts)

1. `omarchy-plugin-add` calls `omarchy-shell shell rescanPlugins`, then polls `omarchy-plugin-list --json` (IPC `listPlugins`) for up to 40 × 0.05 s until the id appears, then calls `omarchy-plugin-enable` exactly once.
2. `omarchy-plugin-enable` runs `omarchy-shell shell enablePlugin "$id" "$placement"` — a single IPC call.
3. `omarchy-shell` wraps every call in `timeout 2s` (`ipc_timeout=${OMARCHY_SHELL_IPC_TIMEOUT:-2s}`) and maps exit 124 to `omarchy-shell is not responding` (bin/omarchy-shell:59–63).
4. After the rescan the shell is in `finishPluginReload` → `Qt.clearComponentCache()` → recreating every panel, service and bar widget synchronously (shell.qml). With enough installed plugins that stretch blocks the QML event loop for more than 2 s, so the discovery poll (answered during/right after scanning) succeeds while the one-shot `enablePlugin` call that follows it times out.

So the race is between the enable call and the shell's own plugin reconstruction that `omarchy-plugin-add` itself triggered one step earlier. The discovery loop is given patience; the enable call is not.

The same 2 s window can also bite a bare `omarchy plugin enable`/`disable` run immediately after any write under `~/.config/omarchy/plugins/` (the inotify watcher starts the same reload).

## Reproduce

On a shell with many plugins installed (15 third-party here — the reload takes several seconds; a nearly stock install usually wins the race):

```
omarchy plugin add https://github.com/nocstah/omachill --enable --yes
# → "Added ..." then "omarchy-shell is not responding"; plugin left disabled
omarchy plugin enable io.github.nocstah.omachill   # succeeds
```

Reproduced twice on 2026-08-30 (17:11 +07 via `plugin add --enable`; also with a plain `enable` right after an rsync into the plugins dir). The shell was healthy throughout — `omarchy-shell shell ping` answers `ok` once the reload finishes.

## Expected

Either the enable call gets the same patience the discovery poll already gets (retry on timeout for a few seconds), or `enablePlugin` is queued by the shell when it arrives mid-reload. Since `omarchy-plugin-add` knows it just triggered the reload, a bounded retry around step 2 seems like the smallest fix.

## Environment

- omarchy 4.0.1-1, quickshell 0.3.1-1, Hyprland 0.56.2 (Lua config), Arch
- 15 third-party plugins installed under `~/.config/omarchy/plugins/`

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