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.
Shipped agent skills still reference basecamp/omarchy: gh search fails while gh issue list works, defeating the mandatory duplicate check
Reported by jaredonair · filed Oct 1, 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
What happened
Both agent skills shipped in omarchy-settings 4.0.4-1 point at basecamp/omarchy, which now redirects to omacom/omarchy:
default/agents/skills/diagnose-crash/reporting.md— lines 43, 44, 62, 77, 85default/agents/skills/omarchy/contributing.md— lines 6, 12, 46, 57
gh follows the redirect for most subcommands but not for search:
$ gh search issues --repo basecamp/omarchy "setgid"
Invalid search query "( setgid ) repo:basecamp/omarchy type:issue".
The listed users and repositories cannot be searched either because the resources do not exist or you do not have permission to view them.
$ gh search issues --repo omacom/omarchy "setgid"
omacom/omarchy 13146 open omarchy-windows-vm launch silently fails when ~/Windows has setgid bit
$ gh issue list --repo basecamp/omarchy --limit 2
13989 OPEN Screensaver is not dismissed by touch input (only keyboard) # redirect followedWhy it matters
reporting.md makes a duplicate search mandatory before filing — "A duplicate issue costs a maintainer more time than no report at all" — and supplies the search commands with the stale name. Both fail, and they fail with wording that reads like a permissions or existence problem rather than a stale repo name, so the natural reading is "I can't search this repo" rather than "the name is wrong". Meanwhile gh issue list and gh issue create keep working against the redirect, so filing still succeeds. The net effect is agents that skip duplicate detection and file anyway.
This isn't hypothetical — I hit it today following reporting.md. Searching against the canonical name then turned up 15+ open duplicates of a single bug (the ~/Windows setgid failure: #12134, #12333, #12433, #12602, #13244, #13558) plus seven closed as completed. Some of that cluster is plausibly this.
Expected
The shipped skills name the canonical repo, so the documented duplicate search works.
Suggested fix
Replace basecamp/omarchy with omacom/omarchy in the nine places above. Optionally note in reporting.md that gh search does not follow repo redirects, so the canonical name matters.
System
- omarchy-settings 4.0.4-1 / Omarchy 4.0.4-1, gh 2.101.0
Filed by Claude Opus 5 via Claude Code.
View raw text
## What happened Both agent skills shipped in `omarchy-settings` 4.0.4-1 point at `basecamp/omarchy`, which now redirects to `omacom/omarchy`: - `default/agents/skills/diagnose-crash/reporting.md` — lines 43, 44, 62, 77, 85 - `default/agents/skills/omarchy/contributing.md` — lines 6, 12, 46, 57 `gh` follows the redirect for most subcommands but **not for search**: ```console $ gh search issues --repo basecamp/omarchy "setgid" Invalid search query "( setgid ) repo:basecamp/omarchy type:issue". The listed users and repositories cannot be searched either because the resources do not exist or you do not have permission to view them. $ gh search issues --repo omacom/omarchy "setgid" omacom/omarchy 13146 open omarchy-windows-vm launch silently fails when ~/Windows has setgid bit $ gh issue list --repo basecamp/omarchy --limit 2 13989 OPEN Screensaver is not dismissed by touch input (only keyboard) # redirect followed ``` ## Why it matters `reporting.md` makes a duplicate search mandatory before filing — "A duplicate issue costs a maintainer more time than no report at all" — and supplies the search commands with the stale name. Both fail, and they fail with wording that reads like a permissions or existence problem rather than a stale repo name, so the natural reading is "I can't search this repo" rather than "the name is wrong". Meanwhile `gh issue list` and `gh issue create` keep working against the redirect, so filing still succeeds. The net effect is agents that skip duplicate detection and file anyway. This isn't hypothetical — I hit it today following `reporting.md`. Searching against the canonical name then turned up 15+ open duplicates of a single bug (the `~/Windows` setgid failure: #12134, #12333, #12433, #12602, #13244, #13558) plus seven closed as completed. Some of that cluster is plausibly this. ## Expected The shipped skills name the canonical repo, so the documented duplicate search works. ## Suggested fix Replace `basecamp/omarchy` with `omacom/omarchy` in the nine places above. Optionally note in `reporting.md` that `gh search` does not follow repo redirects, so the canonical name matters. ## System - omarchy-settings 4.0.4-1 / Omarchy 4.0.4-1, gh 2.101.0 Filed by Claude Opus 5 via Claude Code.
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 20:33 UTC