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 never appears when the adapter is hot-plugged after login (shell never reconnects to org.bluez)
Reported by neodemus · filed Oct 3, 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
- Omarchy 4.0.4-1 (stable channel), Quickshell 0.3.1-1, bluez 5.87-2, kernel 7.2.5-3-omarchy
- Desktop, Gigabyte X570 AORUS ELITE (no onboard Bluetooth), Ryzen 5 3600X, RTX 4060 Ti
- Adapter: USB dongle
0bda:8771Realtek RTL8761BU (btusb, firmware loads fine)
What's wrong?
On a machine that boots without a Bluetooth adapter, plugging in a USB Bluetooth dongle later never makes the omarchy.bluetooth bar widget appear. BlueZ is fully up (bluetoothctl show → Powered: yes), but the bar has no Bluetooth icon and SUPER+CTRL+B opens nothing, for the rest of the session. omarchy restart shell makes the icon appear immediately.
Why
- With no adapter at boot,
/sys/class/bluetoothdoes not exist, sobluetooth.serviceis skipped (ConditionPathIsDirectory=/sys/class/bluetooth).org.bluezis therefore not on the system bus when the shell starts. - The shell tries BlueZ once at startup and logs:
10:22:58.886 WARN quickshell.dbus.objectmanager: Failed to create DBusObjectManagerInterface for "org.bluez" "/" : QDBusError("", "")- When the dongle is plugged in, udev starts
bluetooth.target→bluetooth.service, andorg.bluezappears. The shell log has no further BlueZ line: it does not notice the name appearing, soBluetooth.defaultAdapterstaysnull. shell/plugins/panels/bluetooth/Panel.qml:500hasvisible: adapter !== null, so the widget stays hidden.
The underlying "connect once, never retry" behaviour looks like it lives in Quickshell's Bluetooth service (inferred from the log, I did not read Quickshell's source), but the user-visible result is an Omarchy shell widget that cannot recover without a manual shell restart.
bt-agent.service has the same gap on this path: it was skipped at login by its own ConditionPathIsDirectory=/sys/class/bluetooth and nothing starts it when the adapter appears, so the session also has no pairing agent. That part overlaps with #13247 / #8962 (different trigger, same "skipped for the whole session" outcome).
This is not #7573 (adapter present but panel latched on "Turned Off") and not #13523 (adapter null after rfkill block): here BlueZ itself was absent from the bus when the shell started.
Timeline from the affected session
10:22:57 quickshell starts
10:22:58 WARN Failed to create DBusObjectManagerInterface for "org.bluez"
10:23:28 systemd: Bluetooth service skipped, unmet condition check ConditionPathIsDirectory=/sys/class/bluetooth
15:33:37 bluetooth.service started
15:35:32 usb 3-3: Realtek Bluetooth Radio (0bda:8771) plugged in, hci0 registered, firmware loaded
15:38:51 bluetoothctl show → Controller 00:E0:4C:… Powered: yes; rfkill: not blocked
15:39 bar screenshot: no Bluetooth icon (omarchy.bluetooth is enabled in shell.json bar.right)
15:39:46 omarchy-restart-shell → icon appearsSteps to reproduce
- Boot a machine with no Bluetooth adapter present (desktop without onboard Bluetooth, dongle unplugged) and log in.
- Confirm
systemctl status bluetoothshows the service skipped. - Plug in a USB Bluetooth dongle; wait until
bluetoothctl showreportsPowered: yes. - Look at the bar: no Bluetooth widget. SUPER+CTRL+B does nothing.
- Run
omarchy restart shell: the widget appears.
Observed once on this machine with the evidence above; I have not repeated the cold-boot cycle.
Expected
The Bluetooth widget appears shortly after an adapter is plugged in, without restarting the shell, and the pairing agent is started.
Possible fixes
- Have the shell (or Quickshell upstream) watch for
org.bluezappearing on the system bus and re-create its object manager. - Or ship a user unit
WantedBy=bluetooth.target(the user-manager target udev already pulls in viaSYSTEMD_USER_WANTS) that startsbt-agent.serviceand restarts the shell when bluetoothd started after it.
Workaround in use
A user unit WantedBy=bluetooth.target running this once org.bluez is on the bus:
systemctl --user start bt-agent.service
# restart the shell only if it is older than bluetoothd
((bluez_start > shell_start)) && exec omarchy-restart-shellFiled by Claude Fable 5.1 via Claude Code, on behalf of the machine's owner.
View raw text
### System details
- Omarchy 4.0.4-1 (stable channel), Quickshell 0.3.1-1, bluez 5.87-2, kernel 7.2.5-3-omarchy
- Desktop, Gigabyte X570 AORUS ELITE (no onboard Bluetooth), Ryzen 5 3600X, RTX 4060 Ti
- Adapter: USB dongle `0bda:8771` Realtek RTL8761BU (btusb, firmware loads fine)
### What's wrong?
On a machine that boots **without** a Bluetooth adapter, plugging in a USB Bluetooth dongle later never makes the `omarchy.bluetooth` bar widget appear. BlueZ is fully up (`bluetoothctl show` → `Powered: yes`), but the bar has no Bluetooth icon and SUPER+CTRL+B opens nothing, for the rest of the session. `omarchy restart shell` makes the icon appear immediately.
### Why
1. With no adapter at boot, `/sys/class/bluetooth` does not exist, so `bluetooth.service` is skipped (`ConditionPathIsDirectory=/sys/class/bluetooth`). `org.bluez` is therefore not on the system bus when the shell starts.
2. The shell tries BlueZ once at startup and logs:
```
10:22:58.886 WARN quickshell.dbus.objectmanager: Failed to create DBusObjectManagerInterface for "org.bluez" "/" : QDBusError("", "")
```
3. When the dongle is plugged in, udev starts `bluetooth.target` → `bluetooth.service`, and `org.bluez` appears. The shell log has **no further BlueZ line**: it does not notice the name appearing, so `Bluetooth.defaultAdapter` stays `null`.
4. `shell/plugins/panels/bluetooth/Panel.qml:500` has `visible: adapter !== null`, so the widget stays hidden.
The underlying "connect once, never retry" behaviour looks like it lives in Quickshell's Bluetooth service (inferred from the log, I did not read Quickshell's source), but the user-visible result is an Omarchy shell widget that cannot recover without a manual shell restart.
`bt-agent.service` has the same gap on this path: it was skipped at login by its own `ConditionPathIsDirectory=/sys/class/bluetooth` and nothing starts it when the adapter appears, so the session also has no pairing agent. That part overlaps with #13247 / #8962 (different trigger, same "skipped for the whole session" outcome).
This is not #7573 (adapter present but panel latched on "Turned Off") and not #13523 (adapter null after rfkill block): here BlueZ itself was absent from the bus when the shell started.
### Timeline from the affected session
```
10:22:57 quickshell starts
10:22:58 WARN Failed to create DBusObjectManagerInterface for "org.bluez"
10:23:28 systemd: Bluetooth service skipped, unmet condition check ConditionPathIsDirectory=/sys/class/bluetooth
15:33:37 bluetooth.service started
15:35:32 usb 3-3: Realtek Bluetooth Radio (0bda:8771) plugged in, hci0 registered, firmware loaded
15:38:51 bluetoothctl show → Controller 00:E0:4C:… Powered: yes; rfkill: not blocked
15:39 bar screenshot: no Bluetooth icon (omarchy.bluetooth is enabled in shell.json bar.right)
15:39:46 omarchy-restart-shell → icon appears
```
### Steps to reproduce
1. Boot a machine with no Bluetooth adapter present (desktop without onboard Bluetooth, dongle unplugged) and log in.
2. Confirm `systemctl status bluetooth` shows the service skipped.
3. Plug in a USB Bluetooth dongle; wait until `bluetoothctl show` reports `Powered: yes`.
4. Look at the bar: no Bluetooth widget. SUPER+CTRL+B does nothing.
5. Run `omarchy restart shell`: the widget appears.
Observed once on this machine with the evidence above; I have not repeated the cold-boot cycle.
### Expected
The Bluetooth widget appears shortly after an adapter is plugged in, without restarting the shell, and the pairing agent is started.
### Possible fixes
- Have the shell (or Quickshell upstream) watch for `org.bluez` appearing on the system bus and re-create its object manager.
- Or ship a user unit `WantedBy=bluetooth.target` (the user-manager target udev already pulls in via `SYSTEMD_USER_WANTS`) that starts `bt-agent.service` and restarts the shell when bluetoothd started after it.
### Workaround in use
A user unit `WantedBy=bluetooth.target` running this once `org.bluez` is on the bus:
```bash
systemctl --user start bt-agent.service
# restart the shell only if it is older than bluetoothd
((bluez_start > shell_start)) && exec omarchy-restart-shell
```
Filed by Claude Fable 5.1 via Claude Code, on behalf of the machine's owner.
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 21:03 UTC