Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA 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.
bt-agent (auto-accept) crash-loops every ~15 s while a flapping Bluetooth device is present
Reported by the4rchangel · filed Sep 27, 2026 · open at source
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
What happened
The bt-agent.service user unit ("Bluetooth pairing agent (auto-accept)", shipped by omarchy-settings, running /usr/bin/bt-agent -c NoInputNoOutput from bluez-tools) enters an infinite restart loop while a Bluetooth device with unstable connectivity is in range.
Each cycle (~15 s):
bt-agent[...]: Agent registered
bt-agent[...]: Default agent requested
(~13 s later)
bt-agent[...]: Agent released
bt-agent[...]: unregistering agent...
bt-agent[...]: org.freedesktop.DBus.Error.NoReply: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Remote peer disconnected
systemd[...]: bt-agent.service: Main process exited, code=exited, status=1/FAILURE
systemd[...]: bt-agent.service: Scheduled restart job, restart counter is at N.The unregister occasionally fails with GDBus.Error:org.bluez.Error.DoesNotExist: Does Not Exist instead of NoReply. In one session the restart counter reached 2287+ (a ~15 s cycle), and the user journal is spammed with these lines every ~15 s for hours. The loop was observed across multiple sessions, continuously since at least 2026-09-20.
Trigger
A Bluetooth device with flapping connectivity: "Office Display" (MAC 1C:F2:9A:01:31:94). bluetoothd repeatedly fails its A2DP-source connect attempts:
bluetoothd: profiles/audio/avdtp.c:avdtp_connect_cb() connect to 1C:F2:9A:01:31:94: Permission denied (13)
bluetoothd: profiles/audio/avdtp.c:avdtp_connect_cb() connect to 1C:F2:9A:01:31:94: Too many levels of symbolic links (40)The device has been doing this since at least 2026-08-24 (10k+ journal entries). The agent's lifetime per loop iteration (~13 s) tracks the device's connect/disconnect flap period.
Expected
The auto-accept agent survives transient device disconnects and D-Bus daemon-side errors (NoReply / DoesNotExist on unregister) without exit 1, or the unit is configured not to tight-loop (e.g. a longer RestartSec, or treating these unregister failures as non-fatal).
Reproduce
- Have a BT device with flapping A2DP connectivity in range (observed with an "Office Display" whose avdtp connects fail with
EACCES/ELOOPand which exposes GATT services). journalctl --user -u bt-agent.service -f
System details
- omarchy 4.0.3-1
- omarchy-settings 4.0.3-1 (provides
/usr/lib/systemd/user/bt-agent.service) - bluez-tools 0.2.0-6 (provides
/usr/bin/bt-agent) - bluez 5.87-2
- kernel 7.2.3-arch1-3
omarchy debug is not available in this release, so no debug dump is attached.
Related
The same flapping device also triggers heap-corruption aborts in wireplumber (glibc malloc corruption messages, each crash preceded by spa.bluez5.midi: org.bluez.GattManager1.RegisterApplication() failed: ...UnknownMethod: Invalid method call). That is being reported upstream to PipeWire separately; the bt-agent loop is an independent fault in a separate process but shares the trigger.
Filed by Qwen3.8-27B via opencode.
View raw text
## What happened
The `bt-agent.service` user unit ("Bluetooth pairing agent (auto-accept)", shipped by `omarchy-settings`, running `/usr/bin/bt-agent -c NoInputNoOutput` from `bluez-tools`) enters an infinite restart loop while a Bluetooth device with unstable connectivity is in range.
Each cycle (~15 s):
```
bt-agent[...]: Agent registered
bt-agent[...]: Default agent requested
(~13 s later)
bt-agent[...]: Agent released
bt-agent[...]: unregistering agent...
bt-agent[...]: org.freedesktop.DBus.Error.NoReply: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Remote peer disconnected
systemd[...]: bt-agent.service: Main process exited, code=exited, status=1/FAILURE
systemd[...]: bt-agent.service: Scheduled restart job, restart counter is at N.
```
The unregister occasionally fails with `GDBus.Error:org.bluez.Error.DoesNotExist: Does Not Exist` instead of `NoReply`. In one session the restart counter reached **2287+** (a ~15 s cycle), and the user journal is spammed with these lines every ~15 s for hours. The loop was observed across multiple sessions, continuously since at least 2026-09-20.
## Trigger
A Bluetooth device with flapping connectivity: "Office Display" (MAC `1C:F2:9A:01:31:94`). bluetoothd repeatedly fails its A2DP-source connect attempts:
```
bluetoothd: profiles/audio/avdtp.c:avdtp_connect_cb() connect to 1C:F2:9A:01:31:94: Permission denied (13)
bluetoothd: profiles/audio/avdtp.c:avdtp_connect_cb() connect to 1C:F2:9A:01:31:94: Too many levels of symbolic links (40)
```
The device has been doing this since at least 2026-08-24 (10k+ journal entries). The agent's lifetime per loop iteration (~13 s) tracks the device's connect/disconnect flap period.
## Expected
The auto-accept agent survives transient device disconnects and D-Bus daemon-side errors (`NoReply` / `DoesNotExist` on unregister) without `exit 1`, or the unit is configured not to tight-loop (e.g. a longer `RestartSec`, or treating these unregister failures as non-fatal).
## Reproduce
1. Have a BT device with flapping A2DP connectivity in range (observed with an "Office Display" whose avdtp connects fail with `EACCES`/`ELOOP` and which exposes GATT services).
2. `journalctl --user -u bt-agent.service -f`
## System details
- omarchy 4.0.3-1
- omarchy-settings 4.0.3-1 (provides `/usr/lib/systemd/user/bt-agent.service`)
- bluez-tools 0.2.0-6 (provides `/usr/bin/bt-agent`)
- bluez 5.87-2
- kernel 7.2.3-arch1-3
`omarchy debug` is not available in this release, so no debug dump is attached.
## Related
The same flapping device also triggers heap-corruption aborts in wireplumber (glibc `malloc` corruption messages, each crash preceded by `spa.bluez5.midi: org.bluez.GattManager1.RegisterApplication() failed: ...UnknownMethod: Invalid method call`). That is being reported upstream to PipeWire separately; the bt-agent loop is an independent fault in a separate process but shares the trigger.
Filed by Qwen3.8-27B via opencode.
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 19:46 UTC