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.
Plugin clone silently rejected when username collapses id back into `omarchy.` namespace
Reported by csmithnaill · filed Sep 20, 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
Title: Plugin clone silently rejected when username collapses id back into omarchy. namespace
Body:
What happened: Running omarchy plugin clone omarchy.menu (or any built-in plugin) reports success, but the cloned plugin never loads — it's silently rejected by the live shell.
Cause: omarchy-plugin-clone names clones ${USER}.${source_id#omarchy.}. When the login user is omarchy (the name Omarchy's own installer suggests by default), this collapses back to omarchy.<id> — the same id as the original. PluginRegistry.qml (~line 630) unconditionally rejects any third-party plugin id in the omarchy. namespace, reserved for first-party plugins. The CLI's own success check only greps plugin manifests on disk, not the live accepted registry, so it never catches this.
Where the rejection actually shows: only in the quickshell log at /run/user/1000/quickshell/by-id/<instance>/log.log — nowhere in any omarchy CLI output.
Steps to reproduce:
1. Fresh Omarchy install, keep the suggested default username omarchy.
2. omarchy plugin clone omarchy.menu
3. omarchy plugin list shows the clone as present, but it never becomes the active menu / never loads.
Expected: Either the clone command should reject/rename ids that would collide with the first-party namespace, or it should warn clearly instead of reporting silent success.
Workaround: manually edit the clone's manifest.json, change "id" to something outside omarchy. (e.g. local.<plugin>), keep clonedFrom pointing at the original id, then omarchy-shell shell rescanPlugins and omarchy plugin enable <new-id>.
System details:
- Omarchy version: 4.0.3-3 (try-omarchy-runtime package — running via TryOmarchy on Windows/QEMU)
- Likely affects any fresh install that keeps the installer's suggested default username omarchy
View raw text
Title: Plugin clone silently rejected when username collapses id back into `omarchy.` namespace
Body:
What happened: Running `omarchy plugin clone omarchy.menu` (or any built-in plugin) reports success, but the cloned plugin never loads — it's silently rejected by the live shell.
Cause: `omarchy-plugin-clone` names clones `${USER}.${source_id#omarchy.}`. When the login user is `omarchy` (the name Omarchy's own installer suggests by default), this collapses back to `omarchy.<id>` — the same id as the original. `PluginRegistry.qml` (~line 630) unconditionally rejects any third-party plugin id in the `omarchy.` namespace, reserved for first-party plugins. The CLI's own success check only greps plugin manifests on disk, not the live accepted registry, so it never catches this.
Where the rejection actually shows: only in the quickshell log at `/run/user/1000/quickshell/by-id/<instance>/log.log` — nowhere in any `omarchy` CLI output.
Steps to reproduce:
1. Fresh Omarchy install, keep the suggested default username `omarchy`.
2. `omarchy plugin clone omarchy.menu`
3. `omarchy plugin list` shows the clone as present, but it never becomes the active menu / never loads.
Expected: Either the clone command should reject/rename ids that would collide with the first-party namespace, or it should warn clearly instead of reporting silent success.
Workaround: manually edit the clone's `manifest.json`, change `"id"` to something outside `omarchy.` (e.g. `local.<plugin>`), keep `clonedFrom` pointing at the original id, then `omarchy-shell shell rescanPlugins` and `omarchy plugin enable <new-id>`.
System details:
- Omarchy version: 4.0.3-3 (`try-omarchy-runtime` package — running via TryOmarchy on Windows/QEMU)
- Likely affects any fresh install that keeps the installer's suggested default username `omarchy`
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 19:20 UTC