Conversation
BlueZ only flags the adapter pairable while a default agent is registered, and the non-interactive `bluetoothctl pair` the panel runs does not register one. Whenever bt-agent is not running the kernel negotiates "no bonding": pairing succeeds and audio plays, but the link key is never written to /var/lib/bluetooth. On the next reconnect the device refuses the session key, BlueZ drops the pairing, and the user has to forget and pair again every time. bt-agent is skipped on any machine where /sys/class/bluetooth or bluetoothd appears after the user session starts, which is the normal case for a USB dongle, so this is easy to hit. Raise Pairable around the pair handshake when nothing else holds it and put it back afterwards, so bonding no longer depends on the agent's startup timing. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BntCyAvwXhANA1b4UH9tek
2 of 4 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Bluetooth headphones paired from the Omarchy panel work once, then have to be forgotten and paired again every time they are powered on. "Connect" reports connected but no audio output appears.
Root cause: BlueZ only flags the adapter
Pairablewhile a default agent is registered, and the non-interactivebluetoothctl pairthatomarchy-bluetooth-deviceruns does not register one. Against a non-pairable adapter the kernel forces the "no bonding" authentication requirement (hci_persistent_keyreturns false), so pairing succeeds and audio plays, but the link key is never written to/var/lib/bluetooth.bluetoothctl infoshowsPaired: yes/Bonded: no. On the next reconnect the headphones reject the session-only key, BlueZ wipes the pairing, and the user is back to forget-and-pair.bt-agent.serviceis what normally holdsPairable, but it is skipped whenever/sys/class/bluetoothorbluetoothdshows up after the user session starts, which is the normal case for a USB dongle:Fix
omarchy-bluetooth-device pairraisesPairablearound the pair handshake when nothing else holds it, and lowers it again afterwards. When the agent already holds it the script leaves it alone.Verification
bt-agentstopped andPairable: no, the stock script yieldsBonded: noand no[LinkKey]on disk. The patched script yieldsBonded: yes, a stored[LinkKey], the PipeWire sink up, andPairablerestored tonoafterwards. Subsequent power-cycles reconnect without re-pairing.test/shell.d/bluetooth-test.shcovers the ordering (pairable on before pair, off after) and the leave-alone case../test/cligreen.The
bt-agentstartup race is a separate issue worth its own fix; this change makes bonding independent of it.From Marcus (megamos): regards and thanks to DHH and the team. Loving Omarchy.
🤖 Generated with Claude Code
https://claude.ai/code/session_01BntCyAvwXhANA1b4UH9tek