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.
T2 Macs get vulkan-asahi installed: Vulkan detection matches "Non-VGA" Apple T2 devices as an Apple GPU
Reported by rahulmanuwas · filed Sep 29, 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: MacBookPro16,2 (Intel Iris Plus G7, T2), kernel 7.2.7-arch1-Watanare-T2-1-t2, Omarchy 4.0.4-1
What's wrong
On T2 Macs, Omarchy installs vulkan-asahi (the Apple Silicon GPU driver) next to vulkan-intel, even though the Mac has no Apple GPU.
The Vulkan driver detection uses an unanchored pattern:
lspci | grep -iE "(VGA|Display).*$vendor"The T2 chip shows up as a Non-VGA device, and VGA matches inside Non-VGA:
00:02.0 VGA compatible controller: Intel Corporation Iris Plus Graphics G7 (rev 07)
e6:00.1 Non-VGA unclassified device: Apple Inc. T2 Bridge Controller (rev 01)
e6:00.2 Non-VGA unclassified device: Apple Inc. T2 Secure Enclave Processor (rev 01)So [Apple]=vulkan-asahi fires. The same pattern appears in three places:
install/hardware/vulkan.sh(fresh installs)migrations/1784401744.sh(pre-quattro backfill)bin/omarchy-upgrade-to-quattro(install_hardware_transition_packages)
pacman.log from the install shows it being requested explicitly:
[PACMAN] Running 'pacman -S --noconfirm --needed vulkan-intel vulkan-asahi'The effect is small (14 MiB, plus a Vulkan ICD that can never find a device), but it's wrong on every T2 Mac.
Steps to reproduce
On any T2 MacBook:
lspci | grep -iE "(VGA|Display).*Apple" # matches the T2 lines; expected: no output
pacman -Qi vulkan-asahi | grep -E 'Install Reason|Install Date'Or paste this prompt into a coding agent on the machine:
On this Omarchy install, check whethervulkan-asahiis installed and why. Runlspci, then test the pattern that/usr/share/omarchy/install/hardware/vulkan.shuses (lspci | grep -iE "(VGA|Display).*Apple"), and find the matchingpacman -Sline in/var/log/pacman.log. Tell me whether any line it matched is actually a display controller.
Expected
Only real display controllers match. vulkan-asahi is never installed on x86_64, since Apple Silicon GPUs aren't PCI devices.
Suggested fix
Anchor the match on the lspci class name, which keeps the current VGA/Display semantics exactly:
lspci | grep -iE "^\S+ (VGA compatible controller|Display controller): .*$vendor"Then add a migration that drops vulkan-asahi on x86_64 when a dry run (pacman -Rs --print) shows the removal is clean.
Related: #12076, #11259 and #12681 move vulkan.sh to sysfs class 0x03 matching, which would fix fresh installs as a side effect. None of them cover omarchy-upgrade-to-quattro or remove the package from machines that already have it. A small PR that does both follows.
View raw text
**System details:** MacBookPro16,2 (Intel Iris Plus G7, T2), kernel 7.2.7-arch1-Watanare-T2-1-t2, Omarchy 4.0.4-1 ## What's wrong On T2 Macs, Omarchy installs `vulkan-asahi` (the Apple Silicon GPU driver) next to `vulkan-intel`, even though the Mac has no Apple GPU. The Vulkan driver detection uses an unanchored pattern: ```bash lspci | grep -iE "(VGA|Display).*$vendor" ``` The T2 chip shows up as a *Non-VGA* device, and `VGA` matches inside `Non-VGA`: ``` 00:02.0 VGA compatible controller: Intel Corporation Iris Plus Graphics G7 (rev 07) e6:00.1 Non-VGA unclassified device: Apple Inc. T2 Bridge Controller (rev 01) e6:00.2 Non-VGA unclassified device: Apple Inc. T2 Secure Enclave Processor (rev 01) ``` So `[Apple]=vulkan-asahi` fires. The same pattern appears in three places: - `install/hardware/vulkan.sh` (fresh installs) - `migrations/1784401744.sh` (pre-quattro backfill) - `bin/omarchy-upgrade-to-quattro` (`install_hardware_transition_packages`) `pacman.log` from the install shows it being requested explicitly: ``` [PACMAN] Running 'pacman -S --noconfirm --needed vulkan-intel vulkan-asahi' ``` The effect is small (14 MiB, plus a Vulkan ICD that can never find a device), but it's wrong on every T2 Mac. ## Steps to reproduce On any T2 MacBook: ```bash lspci | grep -iE "(VGA|Display).*Apple" # matches the T2 lines; expected: no output pacman -Qi vulkan-asahi | grep -E 'Install Reason|Install Date' ``` Or paste this prompt into a coding agent on the machine: > On this Omarchy install, check whether `vulkan-asahi` is installed and why. Run `lspci`, then test the pattern that `/usr/share/omarchy/install/hardware/vulkan.sh` uses (`lspci | grep -iE "(VGA|Display).*Apple"`), and find the matching `pacman -S` line in `/var/log/pacman.log`. Tell me whether any line it matched is actually a display controller. ## Expected Only real display controllers match. `vulkan-asahi` is never installed on x86_64, since Apple Silicon GPUs aren't PCI devices. ## Suggested fix Anchor the match on the lspci class name, which keeps the current VGA/Display semantics exactly: ```bash lspci | grep -iE "^\S+ (VGA compatible controller|Display controller): .*$vendor" ``` Then add a migration that drops `vulkan-asahi` on x86_64 when a dry run (`pacman -Rs --print`) shows the removal is clean. Related: #12076, #11259 and #12681 move `vulkan.sh` to sysfs class `0x03` matching, which would fix fresh installs as a side effect. None of them cover `omarchy-upgrade-to-quattro` or remove the package from machines that already have it. A small PR that does both follows.
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
- Related PRpr/11259· 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.
- Out of scopeDecided by agents · verified · 2026-10-09 20:09 UTC