Bluetooth panel loops pairing because bt-agent prompts without a terminal

[jacobaross]

Description

Pairing a Logitech MX Anywhere 3 from the stock Bluetooth panel enters an automatic loop: the row alternates between pairing/connecting states roughly once per second without further user input. The device may connect transiently, but it is not bonded and will not reconnect.

The USB adapter, kernel driver, firmware, BlueZ service, discovery, and direct bluetoothctl pairing all work. The failure is in the stock bt-agent.service integration.

Steps to reproduce

1. Start an Omarchy session with bt-agent.service enabled and active.
2. Open the Bluetooth panel with Super + Ctrl + B.
3. Put a Logitech MX Anywhere 3 into pairing mode.
4. Click Pair once.
5. Observe the row repeatedly alternate between pairing and connecting without any additional input.

Actual behavior

bluetoothd repeatedly rejects the authorization request, while the user service logs an interactive prompt despite having no terminal:

bluetoothd: src/device.c:new_auth() No agent available for request type 2
bluetoothd: device_confirm_passkey: Operation not permitted
bt-agent: Authorize this device pairing (yes/no)? Device: MX Anywhere 3 (...)

The prompt and pairing attempt repeat about once per second. systemctl --user stop bt-agent.service can also remain stuck in deactivating (stop-sigterm) until the bt-agent process is killed.

Expected behavior

One click should authorize a Just Works pairing, create a persistent bond, trust the device, and connect it. The panel should terminate a failed attempt instead of continually retrying.

Root cause evidence

The packaged unit says that NoInputNoOutput auto-accepts pairing:

ExecStart=/usr/bin/bt-agent -c NoInputNoOutput

However, -c NoInputNoOutput in bluez-tools selects the advertised I/O capability; it does not make every authorization callback non-interactive. On this system, bt-agent still reads an Authorize this device pairing (yes/no)? prompt from stdin. Because the systemd user service has no interactive stdin, authorization never completes while the panel continues launching pairing attempts.

After runtime-masking and killing bt-agent.service, the same mouse paired immediately through an interactive bluetoothctl agent. BlueZ then reported:

Paired: yes
Bonded: yes
Trusted: yes
Connected: yes

This differs from #6992 (missing bluez-tools) and #8614 (continuous inquiry/page timeout): /usr/bin/bt-agent is installed and active here, and the decisive failure is its unattended authorization prompt.

System details

• Omarchy: 4.0.2-1
• Kernel: 7.1.9.arch1-2
• BlueZ / bluez-utils: 5.87-2
• bluez-tools: 0.2.0-6
• Adapter: TP-Link UB500 (2357:0604), Realtek RTL8761BU firmware loaded successfully
• Device: Logitech MX Anywhere 3 (Bluetooth LE HID)
• CPU: AMD Ryzen 9 9950X3D
• GPU: AMD Radeon RX 9070 XT

Suggested direction

Use a pairing agent whose unattended Just Works behavior is explicit and testable (potentially BlueZ's maintained bluetoothctl --agent NoInputNoOutput) rather than the old bluez-tools agent, and ensure the panel treats a failed pairing attempt as terminal instead of automatically re-entering the pair/connect cycle.

[omarchybot]

Confirmed, and the mechanism is worse than the report suggests: with the agent Omarchy ships, an unattended Just Works pairing cannot succeed under any flag.

default/systemd/user/bt-agent.service:18 runs bt-agent -c NoInputNoOutput. In bluez-tools 0.2.0, -c only sets the I/O capability handed to RegisterAgent; the callback bodies are separate. Without -d, RequestAuthorization — the callback BlueZ uses for exactly the Just Works flow that NoInputNoOutput selects — prints Authorize this device pairing (yes/no)? and reads the answer with scanf (src/lib/agent-helper.c:200-211). A systemd service gets StandardInput=null, so that read hits EOF immediately and the handler falls through to org.bluez.Error.Rejected. Adding -d does not help: it sets _interactive = FALSE, and the same handler then returns Rejected unconditionally (agent-helper.c:214). There is no PIN-file path either — -p feeds RequestPinCode, RequestPasskey and RequestConfirmation, and RequestAuthorization takes no PIN. So the comment at line 14 of that unit, "NoInputNoOutput auto-accepts pair requests", is not true of this binary. Your reading was right.

That is one of two defects in the unit. The other explains No agent available for request type 2, which means BlueZ had no agent to select at all rather than an agent that refused. ExecCondition=/usr/bin/systemctl is-active --quiet bluetooth.service (line 13) is a one-shot check at start, and the unit is ordered only After=dbus.socket — a user unit cannot order itself after a system unit. install/user/first-run/enable-user-units.sh:15 starts it once with enable --now; after that it starts with graphical-session.target. On any boot where the graphical session beats bluetoothd, that ExecCondition fails, and a failed ExecCondition marks the unit skipped rather than failed — so Restart=on-failure never fires and there is no pairing agent for the rest of the session. systemctl --user status bt-agent.service after such a boot shows it inactive with a condition failure, which would be worth checking next time you see that log line.

Two obvious suspects checked and ruled out. The shell registers no BlueZ agent of its own — nothing under shell/ implements org.bluez.Agent1 or calls RegisterAgent. And bluetoothctl does not register a competing one: bluez 5.87 skips its auto-registration when NON_INTERACTIVE is set (client/main.c:501-504), which is how bin/omarchy-bluetooth-device invokes it. So this is one agent that cannot say yes, not two agents fighting.

The panel is not the source of the roughly one-second cadence. One click runs omarchy-bluetooth-device pair exactly once (Panel.qml:270, bin/omarchy-bluetooth-device:33-38), and the 1s timer in the panel only re-issues StartDiscovery (Panel.qml:508-517). The alternating row is BlueZ and the mouse retrying. Your separate point stands, though: the panel holds the adapter in inquiry for the whole attempt and treats nothing as terminal.

Your suggested direction looks right. For what it is worth, BlueZ's own client already has the auto-accept path bluez-tools lacks: an auto agent capability whose method table answers RequestConfirmation and RequestAuthorization without a human (client/agent.c:336-356), with an explicit warning that it bypasses confirmation. Which agent to ship, and whether to accept that trade, is a decision for the maintainer, so I have not opened a PR.

Reviewed by me and by Codex at xhigh reasoning. It independently confirmed there is no second agent in the shell and that the panel does not retry pairing; it could not establish the -d or PIN-file semantics from the repository alone, which is where the bluez-tools source cited above comes in.

[n0mahd]

I reproduced the No agent available for request type 2 branch on a second hardware stack and found one more lifecycle path to the same symptom.

• Apple MacBook Air M1 (2020), Apple/Asahi Bluetooth controller
• Omarchy 4.0.3-1, kernel 7.1.13-3-1-ARCH, BlueZ 5.87
• bt-agent registered at 09:10:14 and remained active
• bluetoothd was replaced at 09:37:56, but the user service had no lifecycle event and retained the old agent process
• subsequent K850 pairing attempts logged src/device.c:new_auth() No agent available for request type 2 followed by device_confirm_passkey: Operation not permitted

Agent registrations belong to the old BlueZ process, so an active bt-agent.service is not sufficient evidence that the live daemon has an agent. With a supervisor tied to the current org.bluez owner, replacing BlueZ also replaced the agent within one polling interval; the K850 and MX Master 3S both reconnected within 14 seconds.

I split that lifecycle bug into #11936 / #11937 so it stays independent of this issue's unattended-authorization fix.