Proof Portal

Sign in
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-5035GitHub issuePublicReceived

Bluetooth popup shows "No adapter" and hides the power switch after turning Bluetooth off

Reported by demenydavid · filed Sep 11, 2026Closed upstream on 2026-09-20 by bjarneo via an automated message, as a duplicate of #6956 (R-4603). GitHub close reason: completed.

Open at source
Received and recorded verbatim. Nothing has been checked yet.

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?
Not yet mapped to any requirement or component.
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?
Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.

Original report

Bluetooth popup shows "No adapter" and hides the power switch after turning Bluetooth offrevision 1 · captured 2026-10-04 12:10 UTC via poll

System details

Lenovo ThinkPad L14 Gen 5 (21L1002KHV), Intel Core Ultra 5 125U, Intel Meteor Lake Graphics, Omarchy 4.0.3-1 (stable), kernel 7.2.3-arch1-3, quickshell 0.3.1-1, bluez 5.87-2

Debug log: https://logs.omarchy.org/fR0Emw

What's wrong?

Turning Bluetooth off from the bar popup does not show Turned Off with a working power switch. The popup instead says No adapter, the switch disappears, and there is no way to turn Bluetooth back on from that UI.

This is not missing hardware. omarchy-bluetooth-power off applies an rfkill soft block so the off state survives reboot. On this ThinkPad that block is tpacpi_bluetooth_sw, which powers the controller off entirely:

  • bluetoothctl show → No default controller available
  • /sys/class/bluetooth is empty
  • Quickshell Bluetooth.defaultAdapter becomes null

The stock panel is built around that adapter object:

  • Bar widget: visible: adapter !== null (shell/plugins/panels/bluetooth/Panel.qml)
  • Status: if (!adapter) return "No adapter"
  • Switch: visible: !!root.adapter
  • Toggle: if (!adapter) return before omarchy-bluetooth-power

So the same action that turns the radio off also removes the only control that can turn it back on. The popup is a separate overlay window, so it can stay on screen after the switch is gone.

Wi-Fi does not have this hole: NetworkManager still exposes wifiEnabled while the radio is off, so that toggle remains.

Expected

  • Status Turned Off (not No adapter)
  • Power switch stays visible and turns the radio back on
  • Bar icon stays, using the off glyph

Steps to reproduce

  1. Open the Bluetooth bar popup (left-click the Bluetooth icon).
  2. Turn Bluetooth off with the header switch (or right-click the icon).
  3. Observe the popup: No adapter, no switch, empty copy No Bluetooth adapter.
  4. There is no in-popup way to turn it back on. The bar icon can also disappear.

Related follow-on

After turning the radio back on from the CLI (omarchy bluetooth power on / rfkill unblock bluetooth), BlueZ has the adapter immediately, but Quickshell's Bluetooth.defaultAdapter often stays null until omarchy restart shell. So even a correct switch can leave the popup stuck until the shell rebinds BlueZ.

Workaround

omarchy bluetooth power on
omarchy restart shell

Menu path Update → Hardware → Bluetooth (omarchy-restart-bluetooth) also unblocks rfkill.

Suggested fix

Treat “rfkill still lists a bluetooth switch, BlueZ has no adapter” as turned off, not no hardware. Keep the switch visible, call omarchy-bluetooth-power on even when defaultAdapter is null, and keep the bar icon with the off glyph. Optionally rebind/restart the shell if the adapter does not reappear after unblock.

Screenshot of the broken popup is at ~/Pictures/omarchy-bluetooth-no-adapter-bug.png (GitHub cannot attach it via gh; please drag that file onto the issue).

View raw text
### System details

Lenovo ThinkPad L14 Gen 5 (21L1002KHV), Intel Core Ultra 5 125U, Intel Meteor Lake Graphics, Omarchy 4.0.3-1 (stable), kernel 7.2.3-arch1-3, quickshell 0.3.1-1, bluez 5.87-2

Debug log: https://logs.omarchy.org/fR0Emw

### What's wrong?

Turning Bluetooth **off** from the bar popup does not show **Turned Off** with a working power switch. The popup instead says **No adapter**, the switch disappears, and there is no way to turn Bluetooth back on from that UI.

This is not missing hardware. `omarchy-bluetooth-power off` applies an `rfkill` soft block so the off state survives reboot. On this ThinkPad that block is `tpacpi_bluetooth_sw`, which powers the controller off entirely:

- `bluetoothctl show` → `No default controller available`
- `/sys/class/bluetooth` is empty
- Quickshell `Bluetooth.defaultAdapter` becomes `null`

The stock panel is built around that adapter object:

- Bar widget: `visible: adapter !== null` (`shell/plugins/panels/bluetooth/Panel.qml`)
- Status: `if (!adapter) return "No adapter"`
- Switch: `visible: !!root.adapter`
- Toggle: `if (!adapter) return` before `omarchy-bluetooth-power`

So the same action that turns the radio off also removes the only control that can turn it back on. The popup is a separate overlay window, so it can stay on screen after the switch is gone.

Wi-Fi does not have this hole: NetworkManager still exposes `wifiEnabled` while the radio is off, so that toggle remains.

**Expected**

- Status **Turned Off** (not **No adapter**)
- Power switch stays visible and turns the radio back on
- Bar icon stays, using the off glyph

**Steps to reproduce**

1. Open the Bluetooth bar popup (left-click the Bluetooth icon).
2. Turn Bluetooth off with the header switch (or right-click the icon).
3. Observe the popup: **No adapter**, no switch, empty copy **No Bluetooth adapter**.
4. There is no in-popup way to turn it back on. The bar icon can also disappear.

**Related follow-on**

After turning the radio back on from the CLI (`omarchy bluetooth power on` / `rfkill unblock bluetooth`), BlueZ has the adapter immediately, but Quickshell's `Bluetooth.defaultAdapter` often stays `null` until `omarchy restart shell`. So even a correct switch can leave the popup stuck until the shell rebinds BlueZ.

**Workaround**

```bash
omarchy bluetooth power on
omarchy restart shell
```

Menu path Update → Hardware → Bluetooth (`omarchy-restart-bluetooth`) also unblocks rfkill.

**Suggested fix**

Treat “rfkill still lists a bluetooth switch, BlueZ has no adapter” as **turned off**, not **no hardware**. Keep the switch visible, call `omarchy-bluetooth-power on` even when `defaultAdapter` is null, and keep the bar icon with the off glyph. Optionally rebind/restart the shell if the adapter does not reappear after unblock.

Screenshot of the broken popup is at `~/Pictures/omarchy-bluetooth-no-adapter-bug.png` (GitHub cannot attach it via `gh`; please drag that file onto the issue).

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.

No decision has been recorded yet.