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-21GitHub issuePublicDecided· Out of scope

Bluetooth bar toggle can't turn Bluetooth back on once it's off (adapter becomes null)

Reported by Fab1anBecker · filed Sep 28, 2026 · open at source

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 toggle can't turn Bluetooth back on once it's off (adapter becomes null)revision 1 · captured 2026-09-28 21:23 UTC via poll

System details

  • Omarchy: 4.0.4-1 - Quickshell: 0.3.1 (Arch Linux package) - bluez: 5.87-2 - Kernel: 7.2.5-3-omarchy (Linux ... 7.2.5-3-omarchy #1 SMP PREEMPT_DYNAMIC) - CPU: Intel(R) Core(TM) i5-8350U CPU @ 1.70GHz - GPU: Intel Corporation Kaby Lake-R GT2 [UHD Graphics 620]

What's wrong?

What happened

The Bluetooth on/off toggle in the top bar panel (Panel.qml) works to turn
Bluetooth off, but once it's off, clicking the toggle again does nothing —
Bluetooth can never be turned back on from the UI.

Why

toggleBluetooth() in
shell/plugins/panels/bluetooth/Panel.qml is:

function toggleBluetooth() {
if (!adapter) return
Quickshell.execDetached(["omarchy-bluetooth-power", adapter.enabled ? "off" : "on"])
}

omarchy-bluetooth-power off calls rfkill block bluetooth. Once the
adapter is rfkill-blocked, BlueZ removes the controller from D-Bus
entirely (bluetoothctl list returns nothing while blocked), so
Bluetooth.defaultAdapter in Quickshell becomes null. The `if (!adapter)
return guard then makes toggleBluetooth()` a silent no-op — there's no
adapter object left to read .enabled off of, so it can never issue the
"on" command.

The backend script itself is fine: running
omarchy-bluetooth-power on / off / toggle directly from a terminal
works correctly every time. The bug is purely in the QML guard clause
losing the adapter reference it needs to decide which direction to toggle.

Steps to reproduce

  1. Turn Bluetooth off via the bar toggle (or omarchy-bluetooth-power off).
  2. Open the Bluetooth panel again and click the toggle to turn it back on.
  3. Nothing happens — the switch and icon stay in the "off" state.

Confirmed independently of the UI:
- rfkill block bluetooth → bluetoothctl list prints nothing (adapter
gone from D-Bus).
- Quickshell IPC call ipc call omarchy.bluetooth toggleBluetooth while
blocked also does nothing, rfkill list bluetooth shows still blocked.
- omarchy-bluetooth-power on run directly immediately restores it.

Expected

Toggling should work in both directions regardless of whether the adapter
is currently enumerable on D-Bus — e.g. fall back to unconditionally
running omarchy-bluetooth-power toggle, or track last-known enabled
state separately from adapter presence, instead of returning early when
adapter is null.

View raw text
### System details

- Omarchy: 4.0.4-1 - Quickshell: 0.3.1 (Arch Linux package) - bluez: 5.87-2 - Kernel: 7.2.5-3-omarchy (`Linux ... 7.2.5-3-omarchy #1 SMP PREEMPT_DYNAMIC`) - CPU: Intel(R) Core(TM) i5-8350U CPU @ 1.70GHz - GPU: Intel Corporation Kaby Lake-R GT2 [UHD Graphics 620]

### What's wrong?

## What happened

The Bluetooth on/off toggle in the top bar panel (Panel.qml) works to turn
Bluetooth off, but once it's off, clicking the toggle again does nothing —
Bluetooth can never be turned back on from the UI.

## Why

`toggleBluetooth()` in
`shell/plugins/panels/bluetooth/Panel.qml` is:

    function toggleBluetooth() {
      if (!adapter) return
      Quickshell.execDetached(["omarchy-bluetooth-power", adapter.enabled ? "off" : "on"])
    }

`omarchy-bluetooth-power off` calls `rfkill block bluetooth`. Once the
adapter is rfkill-blocked, BlueZ removes the controller from D-Bus
entirely (`bluetoothctl list` returns nothing while blocked), so
`Bluetooth.defaultAdapter` in Quickshell becomes `null`. The `if (!adapter)
return` guard then makes `toggleBluetooth()` a silent no-op — there's no
adapter object left to read `.enabled` off of, so it can never issue the
`"on"` command.

The backend script itself is fine: running
`omarchy-bluetooth-power on` / `off` / `toggle` directly from a terminal
works correctly every time. The bug is purely in the QML guard clause
losing the adapter reference it needs to decide which direction to toggle.

## Steps to reproduce

1. Turn Bluetooth off via the bar toggle (or `omarchy-bluetooth-power off`).
2. Open the Bluetooth panel again and click the toggle to turn it back on.
3. Nothing happens — the switch and icon stay in the "off" state.

Confirmed independently of the UI:
- `rfkill block bluetooth` → `bluetoothctl list` prints nothing (adapter
  gone from D-Bus).
- Quickshell IPC call `ipc call omarchy.bluetooth toggleBluetooth` while
  blocked also does nothing, `rfkill list bluetooth` shows still blocked.
- `omarchy-bluetooth-power on` run directly immediately restores it.

## Expected

Toggling should work in both directions regardless of whether the adapter
is currently enumerable on D-Bus — e.g. fall back to unconditionally
running `omarchy-bluetooth-power toggle`, or track last-known enabled
state separately from `adapter` presence, instead of returning early when
`adapter` is null.

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 20:00 UTC