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.
Bluetooth bar widget disappears entirely when turned off, with no way to turn it back on from the UI
Reported by wb2012sf · filed Sep 19, 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
Turning Bluetooth off via the bar's Bluetooth panel/switch makes the entire widget — icon and toggle — disappear from the bar. There is then no on-screen way to turn Bluetooth back on; you have to drop to a terminal (e.g. omarchy-bluetooth-power on or rfkill unblock bluetooth).
Why
shell/plugins/panels/bluetooth/Panel.qml is registered as the bar widget itself (entryPoints.barWidget: "Panel.qml" in manifest.json), and its root visibility is:
visible: adapter !== nullwhere adapter is Bluetooth.defaultAdapter (Quickshell's BlueZ binding).
Turning Bluetooth off goes through bin/omarchy-bluetooth-power off, which does rfkill block bluetooth (intentionally, per the comments in that script — it's the only way the "off" state survives a reboot, since BlueZ never persists Powered).
The problem: rfkill-blocking doesn't just flip Powered to no on the existing adapter object — bluetoothd removes the adapter from D-Bus entirely. Confirmed with:
$ busctl tree org.bluez # before blocking
└─ /org
└─ /org/bluez
└─ /org/bluez/hci0
└─ ...device paths...
$ omarchy-bluetooth-power off
$ busctl tree org.bluez # after blocking
└─ /org
└─ /org/bluez/org/bluez has zero children once blocked. So Bluetooth.defaultAdapter becomes null, and visible: adapter !== null hides the whole bar widget — there's nothing left on screen to click to turn it back on.
Expected
Turning Bluetooth off should leave a visible, clickable affordance in the bar (showing a clear "off" state, matching what icon already computes for !adapter.enabled — the glyph) so it can be turned back on without a terminal.
Steps to reproduce
- Click the Bluetooth icon in the bar, open the panel.
- Toggle the power switch off.
- Observe the entire Bluetooth widget vanishes from the bar.
- There is no bar element left to click to re-enable it.
System details
- Omarchy version: 4.0.3-1
- Kernel: 7.2.3-arch1-3
- CPU: Intel Core i7-8550U
- GPU: Intel UHD Graphics 620 (Kaby Lake-R)
- Bluetooth controller: Intel Corp. Bluetooth wireless interface (8087:0a2b)
View raw text
## What happened
Turning Bluetooth off via the bar's Bluetooth panel/switch makes the entire widget — icon and toggle — disappear from the bar. There is then no on-screen way to turn Bluetooth back on; you have to drop to a terminal (e.g. `omarchy-bluetooth-power on` or `rfkill unblock bluetooth`).
## Why
`shell/plugins/panels/bluetooth/Panel.qml` is registered as the bar widget itself (`entryPoints.barWidget: "Panel.qml"` in `manifest.json`), and its root visibility is:
```qml
visible: adapter !== null
```
where `adapter` is `Bluetooth.defaultAdapter` (Quickshell's BlueZ binding).
Turning Bluetooth off goes through `bin/omarchy-bluetooth-power off`, which does `rfkill block bluetooth` (intentionally, per the comments in that script — it's the only way the "off" state survives a reboot, since BlueZ never persists `Powered`).
The problem: rfkill-blocking doesn't just flip `Powered` to `no` on the existing adapter object — bluetoothd removes the adapter from D-Bus entirely. Confirmed with:
```
$ busctl tree org.bluez # before blocking
└─ /org
└─ /org/bluez
└─ /org/bluez/hci0
└─ ...device paths...
$ omarchy-bluetooth-power off
$ busctl tree org.bluez # after blocking
└─ /org
└─ /org/bluez
```
`/org/bluez` has zero children once blocked. So `Bluetooth.defaultAdapter` becomes `null`, and `visible: adapter !== null` hides the whole bar widget — there's nothing left on screen to click to turn it back on.
## Expected
Turning Bluetooth off should leave a visible, clickable affordance in the bar (showing a clear "off" state, matching what `icon` already computes for `!adapter.enabled` — the `` glyph) so it can be turned back on without a terminal.
## Steps to reproduce
1. Click the Bluetooth icon in the bar, open the panel.
2. Toggle the power switch off.
3. Observe the entire Bluetooth widget vanishes from the bar.
4. There is no bar element left to click to re-enable it.
## System details
- Omarchy version: 4.0.3-1
- Kernel: 7.2.3-arch1-3
- CPU: Intel Core i7-8550U
- GPU: Intel UHD Graphics 620 (Kaby Lake-R)
- Bluetooth controller: Intel Corp. Bluetooth wireless interface (8087:0a2b)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 15:49 UTC