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.
Installer erases T1/T2 firmware on Apple hardware, permanently disabling Touch Bar / camera / Touch ID
Reported by PaulShadwell · filed Aug 25, 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
Installing Omarchy on a Mac with an Apple T1/T2 chip permanently disables the
Touch Bar, FaceTime camera, Touch ID and ambient light sensor — and nothing in
the installer warns that this will happen.
On these machines the T1/T2 coprocessor loads its firmware from a directory
that macOS maintains on the EFI System Partition. When the installer
replaces the partition map and creates a fresh ESP, that firmware is gone. The
coprocessor then falls back to DFU/recovery mode on every boot:
usb 1-3: New USB device found, idVendor=05ac, idProduct=1281
usb 1-3: Product: Apple Mobile Device (Recovery Mode)
serial: CPID:8002 CPRV:10 CPFM:03 SCEP:01 BDID:12 IBFL:3DA healthy T1 enumerates as 05ac:8600 ("iBridge"). Everything behind it dies
with it:
/sys/bus/hid/devices/is empty — no Touch Bar, and **no Esc or function
keys at all**, since on these models both live in the Touch Bar
- no /dev/video*, uvcvideo never loads — the FaceTime camera is gone
- Touch ID and the ambient light sensor are gone
- the entire USB tree contains only the DFU device
I had deliberately partitioned the drive beforehand to dual-boot, but the
install overwrote the partition map and took the whole disk anyway.
Why this is worse than normal data loss
This is not recoverable from Linux. Apple restricts Configurator revive/restore
to T2 and Apple Silicon — T1 is explicitly excluded
("Other Mac models don't apply"), and there is no documented file-level way to
restore T1 firmware. The only fix is reinstalling macOS, which for a
single-disk machine means wiping the Omarchy install that just replaced it.
So a user who installs Omarchy on a T1 Mac loses Esc, the function row, and the
webcam, and can only get them back by erasing Omarchy again.
Expected
The installer should detect Apple hardware with a T1/T2 coprocessor and, before
touching the partition map, warn that a full-disk install will permanently
disable the Touch Bar, camera and Touch ID until macOS is reinstalled — and
point at the free-space install option that preserves the existing ESP.
Being told before the install rather than discovering it afterwards is the
whole ask. A guard or a confirmation prompt would be enough.
Steps to reproduce
- Take a Touch Bar Mac with a T1 or T2 chip (e.g. MacBookPro14,2) running macOS
- Install Omarchy from the ISO using the standard full-disk path
- Boot Omarchy — the Touch Bar and camera are dead
grep 05ac /sys/bus/usb/devices/*/idVendor→ the device reports1281,
not 8600
Notes
Discussion #2457 covers
the same hardware and notes the "Free space install" option preserves macOS and
the T1 firmware. That option works — but it is only discoverable after you
already know this failure mode exists, which is exactly the gap.
Filing this as an issue rather than a suggestion because the outcome is
permanent hardware loss with no in-place recovery, not a missing feature.
System
| Omarchy | 4.0.1-1 (stable) |
| Kernel | 7.1.9-arch1-2 |
| Model | MacBookPro14,2 (Mac-CAD6701F7CEA0921) |
| Firmware | 529.140.2.0.0, 06/23/2024 |
| CPU | Intel Core i7-7567U |
| GPU | Intel Iris Plus Graphics 650 (Kaby Lake-U GT3) |
| Disk | APPLE SSD AP1024J, 931.8G |
Prior to installing, this machine ran macOS Ventura with a fully working Touch
Bar, so the hardware itself is known good.
View raw text
## What happened
Installing Omarchy on a Mac with an Apple T1/T2 chip permanently disables the
Touch Bar, FaceTime camera, Touch ID and ambient light sensor — and nothing in
the installer warns that this will happen.
On these machines the T1/T2 coprocessor loads its firmware from a directory
that macOS maintains **on the EFI System Partition**. When the installer
replaces the partition map and creates a fresh ESP, that firmware is gone. The
coprocessor then falls back to DFU/recovery mode on every boot:
```
usb 1-3: New USB device found, idVendor=05ac, idProduct=1281
usb 1-3: Product: Apple Mobile Device (Recovery Mode)
serial: CPID:8002 CPRV:10 CPFM:03 SCEP:01 BDID:12 IBFL:3D
```
A healthy T1 enumerates as `05ac:8600` ("iBridge"). Everything behind it dies
with it:
- `/sys/bus/hid/devices/` is empty — no Touch Bar, and **no Esc or function
keys at all**, since on these models both live in the Touch Bar
- no `/dev/video*`, `uvcvideo` never loads — the FaceTime camera is gone
- Touch ID and the ambient light sensor are gone
- the entire USB tree contains only the DFU device
I had deliberately partitioned the drive beforehand to dual-boot, but the
install overwrote the partition map and took the whole disk anyway.
## Why this is worse than normal data loss
This is not recoverable from Linux. Apple restricts Configurator revive/restore
to T2 and Apple Silicon — [T1 is explicitly excluded](https://support.apple.com/en-us/108900)
("Other Mac models don't apply"), and there is no documented file-level way to
restore T1 firmware. The only fix is **reinstalling macOS**, which for a
single-disk machine means wiping the Omarchy install that just replaced it.
So a user who installs Omarchy on a T1 Mac loses Esc, the function row, and the
webcam, and can only get them back by erasing Omarchy again.
## Expected
The installer should detect Apple hardware with a T1/T2 coprocessor and, before
touching the partition map, warn that a full-disk install will permanently
disable the Touch Bar, camera and Touch ID until macOS is reinstalled — and
point at the free-space install option that preserves the existing ESP.
Being told *before* the install rather than discovering it afterwards is the
whole ask. A guard or a confirmation prompt would be enough.
## Steps to reproduce
1. Take a Touch Bar Mac with a T1 or T2 chip (e.g. MacBookPro14,2) running macOS
2. Install Omarchy from the ISO using the standard full-disk path
3. Boot Omarchy — the Touch Bar and camera are dead
4. `grep 05ac /sys/bus/usb/devices/*/idVendor` → the device reports `1281`,
not `8600`
## Notes
Discussion [#2457](https://github.com/basecamp/omarchy/discussions/2457) covers
the same hardware and notes the "Free space install" option preserves macOS and
the T1 firmware. That option works — but it is only discoverable *after* you
already know this failure mode exists, which is exactly the gap.
Filing this as an issue rather than a suggestion because the outcome is
permanent hardware loss with no in-place recovery, not a missing feature.
## System
| | |
|---|---|
| Omarchy | 4.0.1-1 (stable) |
| Kernel | 7.1.9-arch1-2 |
| Model | MacBookPro14,2 (Mac-CAD6701F7CEA0921) |
| Firmware | 529.140.2.0.0, 06/23/2024 |
| CPU | Intel Core i7-7567U |
| GPU | Intel Iris Plus Graphics 650 (Kaby Lake-U GT3) |
| Disk | APPLE SSD AP1024J, 931.8G |
Prior to installing, this machine ran macOS Ventura with a fully working Touch
Bar, so the hardware itself is known good.
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/7064· 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 09:09 UTC