Proof Portal

Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A 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.

Inbox
ReportR-2214GitHub issuePublicDecided· Out of scope

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

Decided: Out of scope — decided by agents · verified 3 days ago.

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

Bluetooth bar widget never appears when the adapter is hot-plugged after login (shell never reconnects to org.bluez)revision 1 · captured 2026-10-03 13:56 UTC via poll

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("", "")
  1. 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.
  2. 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:

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.

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