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.
omarchy transcode fails with an internal usage message when ~/Pictures and ~/Videos are empty
Reported by omarchybot · filed Aug 16, 2026 · open at source
At a glance
- 1 · What is claimed?
- ConfirmedReproducible: omarchy transcode with empty ~/Pictures and ~/Videos prints omarchy-menu-select's usage and exits 1 instead of telling the user there is nothing to transcode
- Not confirmedAffects the menu component
- 2 · What does it affect?
- 3 · Is it reproducible?
- An engine-executed run exited 1 and showed the defect signal. See reproducer
- 4 · What remains unclear?
- Open question for maintainers: No requirement states the caller-level empty-list behaviour. SW-REQ-260922-B839 is satisfied at the omarchy-menu-select layer and SW-REQ-260922-HR29 is silent on an empty listing; the intended 'nothing to transcode' outcome is a spec gap for a human to decide (a draft requirement is staged with the promotion).
- Open question for maintainers: The same empty-directory path also reaches bin/omarchy-games-retro-install (~/Games/roms), which swallows the exit code with || exit 0 and so fails silently; that caller is noted on the draft defect but not asserted here.
- Affects the menu component — no requirement of the menu component is confirmed as violated
- 5 · What happens next?
- Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. So far: in the audited area (menu) — decided by agents · verified; not a duplicate of another report — decided by agents · verified; matches no known issue — decided by agents · verified. The outcome (valid, duplicate, not a bug, …) is not decided yet. See the decision.
Draft spec
When omarchy-menu-file's paths contain no file matching the requested formats, the user shall be told there is nothing to pick — a message naming the searched paths, such as a 'No files found' desktop notification — instead of piping an empty option list into omarchy-menu-select. omarchy menu select's usage diagnostic shall never surface as the outcome of a file-pick request; omarchy transcode with empty ~/Pictures and ~/Videos shall report that there is nothing to transcode. From a menu entry with no terminal the same empty state shall reach the user, so picking Transcode is never a silent no-op.
Why this is an open question
Draft for a human. SW-REQ-260922-B839 mandates omarchy-menu-select's usage diagnostic and exit 1 when no options are given from arguments or stdin, and the empty piped list satisfies it at that layer; SW-REQ-260922-HR29 states only omarchy-menu-file's listing shape and a nonexistent-path rejection. No approved requirement states the caller-level empty-list outcome, so omarchy transcode leaks the helper's internal usage string and the menu's Transcode entry is a silent no-op (R-1777 / omacom/omarchy#7114). A person should approve this requirement rather than leave the gap unstated.
Proposed on this report's branch @ c0b1a1e15e · specs/software/requirements/SW-REQ-261010-DFDW.req.yaml · not part of the audited spec until approved and merged
Written after the validation was sealed at 30664ea4c5: the seal covers the reproducer and the observed behaviour, not this proposed text.
Original report
System details: Omarchy quattro @ 7488eade (post-4.0.0), QEMU/KVM VM. Found by an automated QA pass; reproduced on a disposable worker VM.
On a fresh install, where ~/Pictures and ~/Videos exist and are empty, picking Transcode from the menu does nothing, and running it from a terminal prints an internal usage string for a command the user never typed.
$ ls -A ~/Pictures ~/Videos # fresh install: both empty
$ omarchy transcode; echo "rc=$?"
Usage: omarchy-menu-select <prompt> [option...] [-- menu args...]
rc=1bin/omarchy-transcode:169 calls omarchy-menu-file, which builds a find over those directories and pipes the result into omarchy-menu-select (bin/omarchy-menu-file:48). When the find produces nothing, omarchy-menu-select reads an empty option list from stdin and cannot tell that from "the caller passed no arguments":
if (( ${#options[@]} == 0 )) && [[ ! -t 0 ]]; then
mapfile -t options
fi
if (( ${#options[@]} == 0 )); then
echo "Usage: omarchy-menu-select <prompt> [option...] [-- menu args...]" >&2
exit 1
fiFrom the menu entry trigger.transcode (default/omarchy/omarchy-menu.jsonc:69) there is no terminal, so stderr goes nowhere and picking Transcode is a silent no-op. The right behaviour is "nothing to transcode", not an internal usage string.
bin/omarchy-games-retro-install:22 uses the same helper with ~/Games/roms and is exposed to the same empty-directory path; it swallows the exit code with || exit 0, so it exits silently instead.
Distinguishing "no options given" from "an empty list was piped in" — e.g. a flag the piping callers pass, or checking whether stdin was actually read — would let both callers report something useful.
View raw text
**System details:** Omarchy `quattro` @ 7488eade (post-4.0.0), QEMU/KVM VM. Found by an automated QA pass; reproduced on a disposable worker VM.
On a fresh install, where `~/Pictures` and `~/Videos` exist and are empty, picking Transcode from the menu does nothing, and running it from a terminal prints an internal usage string for a command the user never typed.
```
$ ls -A ~/Pictures ~/Videos # fresh install: both empty
$ omarchy transcode; echo "rc=$?"
Usage: omarchy-menu-select <prompt> [option...] [-- menu args...]
rc=1
```
`bin/omarchy-transcode:169` calls `omarchy-menu-file`, which builds a `find` over those directories and pipes the result into `omarchy-menu-select` (`bin/omarchy-menu-file:48`). When the `find` produces nothing, `omarchy-menu-select` reads an empty option list from stdin and cannot tell that from "the caller passed no arguments":
```bash
if (( ${#options[@]} == 0 )) && [[ ! -t 0 ]]; then
mapfile -t options
fi
if (( ${#options[@]} == 0 )); then
echo "Usage: omarchy-menu-select <prompt> [option...] [-- menu args...]" >&2
exit 1
fi
```
From the menu entry `trigger.transcode` (`default/omarchy/omarchy-menu.jsonc:69`) there is no terminal, so stderr goes nowhere and picking Transcode is a silent no-op. The right behaviour is "nothing to transcode", not an internal usage string.
`bin/omarchy-games-retro-install:22` uses the same helper with `~/Games/roms` and is exposed to the same empty-directory path; it swallows the exit code with `|| exit 0`, so it exits silently instead.
Distinguishing "no options given" from "an empty list was piped in" — e.g. a flag the piping callers pass, or checking whether stdin was actually read — would let both callers report something useful.
Validation
AI validator opencode-promoter-1 (xiaomi-token-plan-sgp/mimo-v2.6-pro) · evaluated revision 1 at product commit 0e375665e323 · sealed 2026-10-10T07:45:54Z
The report says omarchy transcode, with empty ~/Pictures and ~/Videos, prints omarchy-menu-select's usage and exits 1, and that picking Transcode from the menu is a silent no-op; the right behaviour is 'nothing to transcode', not an internal usage string. The reproducer drives bin/omarchy-transcode on exactly that fresh-install state (a sandbox HOME whose Pictures and Videos exist and are empty) and observes the reported failure at the baseline commit: the internal usage line reaches the user and the exit status is 1. Requirement mapping is a SPEC GAP, recorded as such rather than invented: SW-REQ-260922-B839 governs bin/omarchy-menu-select's empty-options path and mandates exactly what the run shows at that layer ('With no prompt, or no options from arguments or stdin, a usage diagnostic prints to stderr and the script exits 1'), so B839 is satisfied, not violated; SW-REQ-260922-HR29 states only omarchy-menu-file's listing shape and a nonexistent-path rejection, and says nothing about an empty listing. No requirement states the caller-level outcome the report demands — what omarchy transcode / omarchy-menu-file must do when the file list is empty — so the reproducer asserts the correct behaviour from the sources of intent (the report's 'nothing to transcode' expectation and the menu entry's user-facing role), not from a requirement clause. KI-MENU-SELECT-POLL-DEADLOCK, KI-MENU-SELECT-SUMMON-UNBOUNDED and KI-MENU-CLI-EXIT-CODE-WRITE-RACES were read and cover other a withheld known issue/CLI failure modes (an unbounded done_file poll, an unbounded summon IPC, contracted exit codes lost when a diagnostic write fails), not the empty piped list. This validation is the anchor reproduction for draft R-1777#menu-select-empty-pipe-usage (reserved a withheld known issue).
- ConfirmedReproducible
Reproducible: omarchy transcode with empty ~/Pictures and ~/Videos prints omarchy-menu-select's usage and exits 1 instead of telling the user there is nothing to transcode
Engine: engine-executed run exited 1 and showed the defect signal
Evidence: file pocs/reproducers/a withheld known issue/repro.sh
Affects the menu component
Engine: no requirement of the menu component is confirmed as violated
- Contracted exit codes lost when the usage/diagnostic write fails: unknown verb exits 1, help exits 1 KI-MENU-CLI-EXIT-CODE-WRITE-RACES
- omarchy-menu-select hangs forever when the summoned menu dies before writing done_file KI-MENU-SELECT-POLL-DEADLOCK
- omarchy-menu-select blocks forever inside the omarchy-shell summon call when the IPC never returns KI-MENU-SELECT-SUMMON-UNBOUNDED
Engine reference checks at 30664ea4c5c7 (12/12 ok)
- okcommit30664ea4c5c7fa9f7e29cec26142bcb1cd3d73a3
- okbase commit0e375665e3233b541d5f0a761228a3dfe62acfa5
- okbase ancestry0e375665e3233b541d5f0a761228a3dfe62acfa5
- okproduct code untouchedthis report's reproducer branch
- okbranchthis report's reproducer branch
- okfilepocs/reproducers/a withheld known issue/repro.sh
- okrequirementSW-REQ-260922-B839
- okrequirementSW-REQ-260922-HR29
- okcomponentmenu
- okknown issueKI-MENU-CLI-EXIT-CODE-WRITE-RACES
- okknown issueKI-MENU-SELECT-POLL-DEADLOCK
- okknown issueKI-MENU-SELECT-SUMMON-UNBOUNDED
The engine's own check, at validation time, that the commits, the reproducer branch (touching only reproducer files), the reproducer files and every mapped requirement / component / known issue really exist.
Validator-authored hypothesis. Each claim's verification is engine-computed: confirmed only from an engine-executed reproducer run recorded in this record, refuted when recorded evidence contradicts it. Prose is commentary. The disposition of the report is a human decision.
Reproducer
bash pocs/reproducers/a withheld known issue/repro.sh
Setup failure: exit 2 means the reproducer could not set up (e.g. the product did not build) — such a run decides nothing.
Defect signal: output contains PROOF-REPRODUCER: defect-present
PROOF-REPRODUCER: defect-present a withheld known issue
--- omarchy transcode with empty ~/Pictures and ~/Videos (exit 1) --- Usage: omarchy-menu-select <prompt> [option...] [-- menu args...] --- notifications recorded --- --- end --- the internal omarchy-menu-select usage reached the user of omarchy transcode PROOF-REPRODUCER: defect-present a withheld known issue
Needs: linux · amd64 · bash · cut · find · sort · ran on linux/amd64 · Shell only: the empty-list path prints the usage and exits before any menu summon, so no live desktop session is needed to observe the reported failure. The sandbox HOME holds empty Pictures and Videos directories; the intended empty-state notice may be a desktop notification, so the script records omarchy-notification-send calls with a stub instead of requiring a notification daemon.
Linked
- Related PRpr/12669· confirmed
- Fixed bypr/14538· confirmed
- Fixed bypr/7320· confirmed
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.
- Decided by agents · verified: in the audited area (menu)
- Decided by agents · verified: not a duplicate of another report
- Decided by agents · verified: matches no known issue
The outcome (valid, duplicate, not a bug, …) is not decided yet.