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

Bluetooth agent stays stale after bluetoothd restarts

Reported by n0mahd · filed Sep 15, 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 agent stays stale after bluetoothd restartsrevision 1 · captured 2026-09-28 21:23 UTC via poll

System details

  • Apple MacBook Air M1 (2020), aarch64
  • Omarchy 4.0.3-1
  • Linux 7.1.13-3-1-ARCH
  • BlueZ 5.87
  • Logitech K850 and MX Master 3S (BLE HID)

What's wrong?

bt-agent.service remains active when bluetooth.service is restarted, but its AgentManager registration belonged to the old bluetoothd process. The replacement daemon has no default agent, so subsequent pair requests fail even though systemd still reports the user agent as active.

This happened here when another system service restarted BlueZ, but it reproduces with a deliberate systemctl restart bluetooth.service too.

Reproduction

  1. Start bt-agent.service and confirm Agent registered / Default agent requested.
  2. Record the agent PID.
  3. Restart bluetooth.service.
  4. Confirm that bt-agent.service is still active with the same PID and has not logged another registration.
  5. Attempt to pair a BLE keyboard or mouse.

The user agent was registered at 09:10. BlueZ was replaced at 09:37, while the user unit logged no lifecycle event. Pairing immediately afterward produced:

bluetoothd: src/device.c:new_auth() No agent available for request type 2
bluetoothd: device_confirm_passkey: Operation not permitted

Because bt-agent remains alive, Restart=on-failure does not help. Agent registration is state inside the particular bluetoothd process that accepted it.

Expected behavior

The pairing agent should re-register promptly whenever the org.bluez owner changes. Systemd should not report a healthy pairing agent that the live BlueZ daemon does not know about.

Verified control

I wrapped the packaged agent with a small supervisor that watches the org.bluez owner and exits/restarts the agent when that owner changes. Across two forced BlueZ restarts:

  • the user agent relaunched and logged Agent registered / Default agent requested within one second;
  • both BLE HID devices preserved their bonds;
  • the keyboard and mouse automatically reconnected within 14 seconds;
  • no new missing-agent or authentication errors appeared.

This is related to #8962, but that issue covers the initial user/system service startup race. Here the agent starts and registers successfully, then becomes stale after a later daemon replacement. It also affects any replacement agent that registers only once and remains alive after org.bluez changes.

View raw text
### System details

- Apple MacBook Air M1 (2020), aarch64
- Omarchy 4.0.3-1
- Linux 7.1.13-3-1-ARCH
- BlueZ 5.87
- Logitech K850 and MX Master 3S (BLE HID)

### What's wrong?

`bt-agent.service` remains active when `bluetooth.service` is restarted, but its AgentManager registration belonged to the old `bluetoothd` process. The replacement daemon has no default agent, so subsequent pair requests fail even though systemd still reports the user agent as active.

This happened here when another system service restarted BlueZ, but it reproduces with a deliberate `systemctl restart bluetooth.service` too.

### Reproduction

1. Start `bt-agent.service` and confirm `Agent registered` / `Default agent requested`.
2. Record the agent PID.
3. Restart `bluetooth.service`.
4. Confirm that `bt-agent.service` is still active with the same PID and has not logged another registration.
5. Attempt to pair a BLE keyboard or mouse.

The user agent was registered at 09:10. BlueZ was replaced at 09:37, while the user unit logged no lifecycle event. Pairing immediately afterward produced:

```
bluetoothd: src/device.c:new_auth() No agent available for request type 2
bluetoothd: device_confirm_passkey: Operation not permitted
```

Because `bt-agent` remains alive, `Restart=on-failure` does not help. Agent registration is state inside the particular `bluetoothd` process that accepted it.

### Expected behavior

The pairing agent should re-register promptly whenever the `org.bluez` owner changes. Systemd should not report a healthy pairing agent that the live BlueZ daemon does not know about.

### Verified control

I wrapped the packaged agent with a small supervisor that watches the `org.bluez` owner and exits/restarts the agent when that owner changes. Across two forced BlueZ restarts:

- the user agent relaunched and logged `Agent registered` / `Default agent requested` within one second;
- both BLE HID devices preserved their bonds;
- the keyboard and mouse automatically reconnected within 14 seconds;
- no new missing-agent or authentication errors appeared.

This is related to #8962, but that issue covers the initial user/system service startup race. Here the agent starts and registers successfully, then becomes stale after a later daemon replacement. It also affects any replacement agent that registers only once and remains alive after `org.bluez` changes.

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 13:42 UTC