Arch Linux User Repository

@RedlineGT Great, that's the fix landing - the device showing up in the scan means Web Bluetooth is now working (that was the actual gap: upstream never enables Chromium's WebBluetooth Blink feature on Linux, so navigator.bluetooth didn't exist). I'll roll --enable-blink-features=WebBluetooth into the launcher so the next release works without the flag.

The le-connection-abort-by-local you're hitting now is a separate, later step: scan/pick succeeded, but the LE connection got torn down on the local side (BlueZ, driven by Chromium's Web Bluetooth stack). The telltale sign of this error is that BlueZ briefly marks the device "Connected" and then aborts - so it's a setup-then-teardown, not the pet refusing. Across other BlueZ reports of this exact error, the usual causes are (1) another process holding the adapter and (2) a stale bond, and it's frequently transient - a plain retry often just works. Try, in order:

1. Just retry the connect a couple of times. This error is often intermittent; BlueZ needs a moment to settle after the abort before the next attempt succeeds. Cheapest thing to try first.

2. Make sure nothing else is using the adapter while you connect - close KDE's Bluetooth applet and any bluetoothctl scan on you left running (you were scanning manually earlier to prove the device existed). A concurrent scan/connection on hci0 is the most common cause of this abort.

3. Clear any cached bond, then retry: bluetoothctl remove 14:C1:9F:D4:FA:41

4. Bounce the controller: bluetoothctl power off then power on, and try again.

5. If it prompts for a passkey, enter it in the Hardware Buddy window (the pet uses encrypted pairing).

If it still aborts after all that, grab journalctl -b -u bluetooth around the attempt - that'll show whether BlueZ or the app initiated the teardown. Heads-up: Web Bluetooth on Linux is still flagged experimental by Chromium, and LE-connect aborts are a known rough edge of that path - so if the steps above don't take, it may be the browser stack rather than your setup (nothing you can fix locally in that case). I don't have a Hardware Buddy anymore, so your reports are what let me trace this end to end - much appreciated.

For reference, this error is well-documented against BlueZ generally (mostly via the Bleak Python library, but same stack underneath): bleak #1858 - abort with multiple processes / high load, bleak #1673, bleak #993.

Also noting the device repo here for documentation: https://github.com/anthropics/claude-desktop-buddy

@patrickjaja, finally! some movement :) now it shows up in the list when it scans but falls into this issue.

 claude-desktop --enable-blink-features=WebBluetooth

[claude-cu] mode=kwin-wayland (auto: KDE Wayland + kwin-portal-bridge at /usr/lib/claude-desktop-bin/resources/kwin-portal-bridge, 6.7.3)
[quick-entry] socket trigger ready: /run/user/1000/claude-desktop-qe.sock
[81572:0720/181550.263120:ERROR:dbus/object_proxy.cc:572] Failed to call method: org.freedesktop.systemd1.Manager.StartTransientUnit: object_path= /org/freedesktop/systemd1: org.freedesktop.systemd1.UnitExists: Unit app-com.anthropic.Claude-81572.scope was already loaded or has a fragment file.
[cdb-flags] applying 1 GrowthBook override(s): 2358734848=true
[81572:0720/181617.515561:ERROR:components/device_event_log/device_event_log_impl.cc:202] [18:16:17.515] Bluetooth: bluetooth_device_bluez.cc:1147 /org/bluez/hci0/dev_14_C1_9F_D4_FA_41: Failed to connect device: org.bluez.Error.Failed: le-connection-abort-by-local
[81572:0720/181736.229852:ERROR:components/device_event_log/device_event_log_impl.cc:202] [18:17:36.229] Bluetooth: bluetooth_device_bluez.cc:1147 /org/bluez/hci0/dev_14_C1_9F_D4_FA_41: Failed to connect device: org.bluez.Error.Failed: le-connection-abort-by-local
[81572:0720/181746.153905:ERROR:components/device_event_log/device_event_log_impl.cc:202] [18:17:46.153] Bluetooth: bluetooth_device_bluez.cc:1147 /org/bluez/hci0/dev_14_C1_9F_D4_FA_41: Failed to connect device: org.bluez.Error.Failed: le-connection-abort-by-local
[81572:0720/181814.740283:ERROR:components/device_event_log/device_event_log_impl.cc:202] [18:18:14.740] Bluetooth: bluetooth_device_bluez.cc:1147 /org/bluez/hci0/dev_14_C1_9F_D4_FA_41: Failed to connect device: org.bluez.Error.Failed: le-connection-abort-by-local

@RedlineGT can you try launching it like that claude-desktop --enable-blink-features=WebBluetooth? Does it show up then?

@patrickjaja updated. no joy. still same issue. ran your 4 set of commands again. same result. in chrome i usually have to enable "enable-experimental-web-platform-features" when trying to pair with bluetooth devices. is there something equivalent we can try to see if that helps? Thank you for working with me on this. Its trivial but its a small QoL thing this pet brings :)

@RedlineGT Thanks for the detailed output - that's exactly what let me trace it. I don't have a Hardware Buddy anymore so I can't fully verify, but I'm fairly confident it's fixed in 1.22209.3-3 (just hit the AUR). Update with yay -Syu, make sure the bluez service is running, and let me know if the pet shows up in the scan now.

A few things that would help most:

• The exact name the pet advertises in step 2. The app only matches devices whose name starts with nibblet or claude. I did not see any names in terminal, but my GUI version shows Claude-FA41.
• Whether step 3 shows Experimental = true (if not, that's the likely fix: set it in [General], then sudo systemctl restart bluetooth).
• The output of step 4, specifically whether it says saw 0 stick(s) or saw N stick(s), none matched.

Here is the output of the set of commands you suggested:

# 1. Is bluez installed and running?
bluetoothctl --version
systemctl status bluetooth

# 2. Does BlueZ see the pet BY NAME? (let it run ~15s)
bluetoothctl scan on
# -> note the exact advertised NAME of the pet (not just its MAC)

# 3. Is BlueZ's experimental interface on? (Chromium Web Bluetooth on Linux often needs it)
grep -i experimental /etc/bluetooth/main.conf

# 4. Our own scan log (after trying an in-app scan once):
grep -a '\[buddy-ble\]' ~/.config/Claude/logs/main.log

bluetoothctl --version:

5.87

systemctl status bluetooth:

● bluetooth.service - Bluetooth service
     Loaded: loaded (/usr/lib/systemd/system/bluetooth.service; enabled; preset: disabled)
     Active: active (running) since Mon 2026-07-20 13:34:10 EDT; 5min ago
 Invocation: 070279c5293e4a7fa5be213e08da6460
       Docs: man:bluetoothd(8)
   Main PID: 933 (bluetoothd)
     Status: "Running"
      Tasks: 1 (limit: 37859)
     Memory: 3.2M (peak: 4M)
        CPU: 75ms
     CGroup: /system.slice/bluetooth.service
             └─933 /usr/lib/bluetooth/bluetoothd

Jul 20 13:34:19 ObsidianLegion bluetoothd[933]: Endpoint registered: sender=:1.50 path=/MediaEndpoint/A2DPSource/aptx_ll_duplex_1
Jul 20 13:34:19 ObsidianLegion bluetoothd[933]: Endpoint registered: sender=:1.50 path=/MediaEndpoint/A2DPSource/aptx_ll_duplex_0
Jul 20 13:34:19 ObsidianLegion bluetoothd[933]: Endpoint registered: sender=:1.50 path=/MediaEndpoint/A2DPSource/faststream
Jul 20 13:34:19 ObsidianLegion bluetoothd[933]: Endpoint registered: sender=:1.50 path=/MediaEndpoint/A2DPSource/faststream_duplex
Jul 20 13:34:19 ObsidianLegion bluetoothd[933]: Endpoint registered: sender=:1.50 path=/MediaEndpoint/A2DPSink/opus_05
Jul 20 13:34:19 ObsidianLegion bluetoothd[933]: Endpoint registered: sender=:1.50 path=/MediaEndpoint/A2DPSource/opus_05
Jul 20 13:34:19 ObsidianLegion bluetoothd[933]: Endpoint registered: sender=:1.50 path=/MediaEndpoint/A2DPSink/opus_05_duplex
Jul 20 13:34:19 ObsidianLegion bluetoothd[933]: Endpoint registered: sender=:1.50 path=/MediaEndpoint/A2DPSource/opus_05_duplex
Jul 20 13:35:38 ObsidianLegion bluetoothd[933]: Path / reserved for Adv Monitor app :1.80
Jul 20 13:35:38 ObsidianLegion bluetoothd[933]: Adv Monitor app :1.80 disconnected from D-Bus

bluetoothctl scan on:

SetDiscoveryFilter success

grep -i experimental /etc/bluetooth/main.conf:

# Enables D-Bus experimental interfaces
Experimental = true
# Enables kernel experimental features, alternatively a list of UUIDs
# d4992530-b9ec-469f-ab01-6c481c47da1c (BlueZ Experimental Debug)
# 671b10b5-42c0-4696-9227-eb28d1b049d6 (BlueZ Experimental Simultaneous Central and Peripheral)
# 15c0a148-c273-11ea-b3de-0242ac130004 (BlueZ Experimental LL privacy)
# 330859bc-7506-492d-9370-9a6f0614037f (BlueZ Experimental Bluetooth Quality Report)
# a6695ace-ee7f-4fb9-881a-5fac66c629af (BlueZ Experimental Offload Codecs)
# 6fbaf188-05e0-496a-9885-d6ddfdb4e03e (BlueZ Experimental ISO socket)
#KernelExperimental = false

grep -a '\[buddy-ble\]' ~/.config/Claude/logs/main.log: Yielded nothing.

That last line tells us whether Chromium never got the device (a BlueZ config issue) or got it but the name filter dropped it (something we can fix on our side).

Also, which distro you're on. Thanks!

I am on CachyOS (latest). Thank you for taking the time for such a curated response.

Thanks for the report! The in-app scan uses Chromium's Web Bluetooth talking to your system's BlueZ - your OS bluetooth scanner and the app are two separate consumers of BlueZ, so one seeing the pet doesn't guarantee the other does. A couple of quick CLI checks will tell us exactly where it's breaking (no need to fight with the app):

# 1. Is bluez installed and running?
bluetoothctl --version
systemctl status bluetooth

# 2. Does BlueZ see the pet BY NAME? (let it run ~15s)
bluetoothctl scan on
#    -> note the exact advertised NAME of the pet (not just its MAC)

# 3. Is BlueZ's experimental interface on? (Chromium Web Bluetooth on Linux often needs it)
grep -i experimental /etc/bluetooth/main.conf

# 4. Our own scan log (after trying an in-app scan once):
grep -a '\[buddy-ble\]' ~/.config/Claude/logs/main.log

A few things that would help most: - The exact name the pet advertises in step 2 - the app only matches devices whose name starts with nibblet or claude. - Whether step 3 shows Experimental = true (if not, that's the likely fix: set it in [General], then sudo systemctl restart bluetooth). - The output of step 4 - specifically whether it says saw 0 stick(s) or saw N stick(s), none matched.

That last line tells us whether Chromium never got the device (a BlueZ config issue) or got it but the name filter dropped it (something we can fix on our side). Also which distro you're on. Thanks!

is anyone having issues connecting to the claude desktop pet? my computers bluetooth scan shows it, but when i scan for it in the claude desktop app it cannot see it.

From my reading of it: @kevindiaz314 meant to leave their comment on a different package (likely claude-desktop-official-bin), and not this one.

Thanks @mrdhakal, @cF1nny. Honestly I wasn't going to comment on the wrong info - everyone should use whatever fits their setup, and I've no issue with the other packages. I'm only clarifying because people are getting confused.

claude-desktop-bin is maintained by me (patrickjaja) and isn't deprecated. I don't maintain claude-desktop / claude-desktop-official-bin - those are @kevindiaz314's - so the "same maintainer / deprecated" note and the deletion request (why and how i should get deleted) here are from a non-maintainer, not an agreed migration.

For the actual difference between this and the official- packages, see my 07-01 comment: same official Anthropic .deb underneath; the official- ones install it as-is, this one adds open-source patches on top. It auto-updates daily (semi automated because of quality gates) - current version 1.19367.0, matching upstream.

Either way, I'll keep doing my best to serve all of us Linux users across our different setups. Pick whichever you prefer. Bugs/PRs: https://github.com/patrickjaja/claude-desktop-bin/issues