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

omarchy-restart-bluetooth does not restart bluetooth.service, leaving wedged adapters unrecoverable via GUI or menu

Reported by gbyoung · filed Sep 24, 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

omarchy-restart-bluetooth does not restart bluetooth.service, leaving wedged adapters unrecoverable via GUI or menurevision 1 · captured 2026-09-28 21:23 UTC via poll

System details

Intel Pentium Silver N6000, Intel JasperLake [UHD Graphics], Lenovo IdeaPad 1 15IJL7, Omarchy 4.0.2-1 (Kernel 7.1.9-arch1-2)

What's wrong?

Summary

When a Bluetooth adapter re-enumerates (e.g. firmware reload after suspend or controller bounce), bluetoothd can lose sync with D-Bus adapter state. In this condition:
1. The status bar panel (/usr/share/omarchy/shell/plugins/panels/bluetooth/Panel.qml) cannot toggle Bluetooth back on because adapter evaluates to null and toggleBluetooth() exits early (if (!adapter) return).
2. The user menu recovery action under Update Hardware → Bluetooth (omarchy-restart-bluetooth / omarchy restart bluetooth) fails to recover the adapter. Despite its docstring stating "Unblock and restart the bluetooth service.", the script only runs:

   rfkill unblock bluetooth
   rfkill list bluetooth

It never actually restarts bluetooth.service.

Steps to reproduce

  1. Have a system where bluetoothd has been running and the controller bounces or desyncs (or simulate by stopping/wedging the service with rfkill unblocked).
  2. Attempt to toggle Bluetooth in the Omarchy shell bar popup: the switch does nothing because adapter is null.
  3. Use the system recovery menu (Update Hardware → Bluetooth or omarchy restart bluetooth): the floating terminal displays Unblocking bluetooth... and immediately exits. The adapter remains off/unresponsive.
  4. Run systemctl restart bluetooth: the service immediately recovers, bluetoothd re-registers D-Bus endpoints, and the Omarchy GUI panel toggle immediately begins working again.

Expected behavior

omarchy-restart-bluetooth should restart the Bluetooth daemon (e.g. systemctl restart bluetooth), matching its documented summary and following the pattern of omarchy-restart-audio and omarchy-restart-wifi.

Diagnostic information

From omarchy-debug:
- Omarchy version: 4.0.2-1
- Kernel: 7.1.9-arch1-2 (x86_64)
- Desktop: Hyprland 0.56.2
- Controller: Intel Bluetooth (hci0, ibt-19-0-4.sfi)
- Recovery confirmed by systemctl restart bluetooth

View raw text
### System details
Intel Pentium Silver N6000, Intel JasperLake [UHD Graphics], Lenovo IdeaPad 1 15IJL7, Omarchy 4.0.2-1 (Kernel 7.1.9-arch1-2)

### What's wrong?

#### Summary
When a Bluetooth adapter re-enumerates (e.g. firmware reload after suspend or controller bounce), `bluetoothd` can lose sync with D-Bus adapter state. In this condition:
1. The status bar panel (`/usr/share/omarchy/shell/plugins/panels/bluetooth/Panel.qml`) cannot toggle Bluetooth back on because `adapter` evaluates to `null` and `toggleBluetooth()` exits early (`if (!adapter) return`).
2. The user menu recovery action under **Update Hardware → Bluetooth** (`omarchy-restart-bluetooth` / `omarchy restart bluetooth`) fails to recover the adapter. Despite its docstring stating `"Unblock and restart the bluetooth service."`, the script only runs:
   ```bash
   rfkill unblock bluetooth
   rfkill list bluetooth
   ```
   It never actually restarts `bluetooth.service`.

#### Steps to reproduce
1. Have a system where `bluetoothd` has been running and the controller bounces or desyncs (or simulate by stopping/wedging the service with rfkill unblocked).
2. Attempt to toggle Bluetooth in the Omarchy shell bar popup: the switch does nothing because `adapter` is null.
3. Use the system recovery menu (**Update Hardware → Bluetooth** or `omarchy restart bluetooth`): the floating terminal displays `Unblocking bluetooth...` and immediately exits. The adapter remains off/unresponsive.
4. Run `systemctl restart bluetooth`: the service immediately recovers, `bluetoothd` re-registers D-Bus endpoints, and the Omarchy GUI panel toggle immediately begins working again.

#### Expected behavior
`omarchy-restart-bluetooth` should restart the Bluetooth daemon (e.g. `systemctl restart bluetooth`), matching its documented summary and following the pattern of `omarchy-restart-audio` and `omarchy-restart-wifi`.

#### Diagnostic information
From `omarchy-debug`:
- Omarchy version: 4.0.2-1
- Kernel: 7.1.9-arch1-2 (x86_64)
- Desktop: Hyprland 0.56.2
- Controller: Intel Bluetooth (`hci0`, `ibt-19-0-4.sfi`)
- Recovery confirmed by `systemctl restart bluetooth`

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 02:32 UTC