# Bluetooth stops working after suspend on Omarchy
Bluetooth dead, stuck on Turned Off, or paired mice not reconnecting after resume on Omarchy 4. The shell restart, the bluez restart, and the firmware cases.
> **Short answer:** Most of the time the radio is fine and only the bar panel is wrong. Run `bluetoothctl show`; if it reports Powered yes while the panel says Turned Off, run `omarchy restart shell` and the panel resyncs. If the adapter is genuinely gone, run `omarchy restart bluetooth` then `sudo systemctl restart bluetooth.service`.
- Applies to Omarchy: 4.0.0 and later
- Status: workaround
- Last verified: 2026-09-16
- Canonical: https://omarchylinux.org/fix/bluetooth-stops-after-resume/
_Unofficial community page. Not affiliated with 37signals or the Omacom Foundation. Omarchy is a registered trademark of 37signals LLC._

Bluetooth going quiet after a suspend is one problem name covering at least three different faults on Omarchy 4. Work through them in order. The first one is by far the most common, and it does not involve the radio at all.

## The fix

Checked on 4.0.4. Steps 1 and 2 apply to 4.0.0 and later only, since the Quickshell Bluetooth panel arrived in 4.0.0 (Quattro).

**1. Find out whether the radio is actually down.**

```bash
bluetoothctl show | grep -E 'Powered|PowerState'
rfkill list bluetooth
omarchy bluetooth power is-on; echo "exit $?"
```

If you get `Powered: yes`, `PowerState: on`, no soft or hard block, and exit 0, the radio is alive and the bar is lying to you. Go to step 2. If `bluetoothctl show` prints `No default controller available`, skip to step 3.

**2. Restart the Omarchy shell.**

```bash
omarchy restart shell
```

The panel picks up the live BlueZ state again, the toggle works, and paired devices show up. This is the fix for the panel reading `Turned Off` while everything underneath is fine, reported in [#7573](https://github.com/omacom/omarchy/issues/7573) and [#9561](https://github.com/omacom/omarchy/issues/9561). You lose nothing but the shell process. Expect to repeat it after future resumes; no fix had shipped in Omarchy or Quickshell as of 4.0.4. One reporter on #9561 resyncs the panel without a shell restart by cycling rfkill, `rfkill block bluetooth && sleep 0.5 && rfkill unblock bluetooth`, but on ThinkPads and some Dells a type-wide block can drop the radio off the USB bus (see below), so prefer the shell restart there.

**3. If the adapter is gone, unblock then restart bluez.**

```bash
omarchy restart bluetooth
sudo systemctl restart bluetooth.service
```

Note what the first command actually does in 4.0.4: it runs `rfkill unblock bluetooth` and prints the rfkill table. Despite the name and the menu entry under _Update > Hardware > Bluetooth_, it does not restart the service. That is why the second line is there. If the controller still does not appear, the hardware-specific recoveries are in the last section. Reloading `btusb` is not one of them: on the threads where people tried it, the controller came back in the same broken state.

**4. If paired mice or keyboards will not reconnect, check for a stuck scan.**

```bash
busctl --system get-property org.bluez /org/bluez/hci0 org.bluez.Adapter1 Discovering
```

If that says `true` with the Bluetooth panel closed, the adapter is pinned in discovery and bonded LE devices cannot get back in. Power cycle the adapter:

```bash
bluetoothctl power off && sleep 1 && bluetoothctl power on
```

That is what most reporters on [#10818](https://github.com/omacom/omarchy/issues/10818) used, and the mouse or keyboard reconnected afterwards with no re-pairing. One reporter used `sudo systemctl restart bluetooth.service` instead with the same result. `bluetoothctl scan off` and `omarchy restart shell` do not clear it. Keep the panel closed while switching a multi-host mouse or keyboard back to this machine.

**5. If pairing fails after bluetooth.service restarted.**

```bash
systemctl --user restart bt-agent.service
```

[#11936](https://github.com/omacom/omarchy/issues/11936) shows why: the pairing agent registers with one `bluetoothd` process, and when that process is replaced, including by the restart in steps 3 and 4, the new daemon has no agent while systemd still reports `bt-agent.service` as healthy. The reporter's fix relaunches the agent whenever the `org.bluez` owner changes; restarting the unit by hand does the same once.

## Verify it worked

```bash
bluetoothctl show | grep -E 'Powered|Discovering'
bluetoothctl devices Connected
```

You want `Powered: yes`, `Discovering: no` with the panel closed, and your device listed as connected. Then open the panel with `Super + Ctrl + B` and confirm it agrees with those numbers. Suspend and resume once more and check again, because the panel fault only reappears on a resume.

## Why it happens

Three separate mechanisms produce the same complaint.

**The panel holds a stale power state.** On many controllers a resume tears the adapter down and brings it back, reloading firmware as it goes. BlueZ reports the adapter as not powered during that window, then powers it up. In Quickshell 0.3.1 the Bluetooth adapter object takes a one-time property snapshot and subscribes to later changes, and the completion event can land in the gap between those two moments. Nothing re-reads the value afterwards. JareckiB12 instrumented a resume on [#7573](https://github.com/omacom/omarchy/issues/7573) and found the final recorded write set the powered flag to false while BlueZ itself reported the controller as on four minutes later. The panel then renders `Turned Off`, its device list stays empty, and its switch sends the on command forever.

**The adapter is stuck in discovery.** While the panel is open it re-asserts discovery every second. On close it tries to stop it, but gives up after three attempts, and an active scan aborts the LE connects that bonded mice and keyboards need to come back. Reporters on [#10818](https://github.com/omacom/omarchy/issues/10818) found the same stuck `Discovering: true` on Intel 8265, AX200, AX210, a PCIe Intel controller and a MediaTek MT7922, so it is not chipset specific, but the panel is not always the owner. One reporter traced the leaked session to a Chrome passkey prompt, and another showed that in BlueZ 5.87 a failed `StopDiscovery` leaves the flag set with no client owning it, so every later stop is refused with `No discovery started` and only powering the adapter down resets it. A related storm, [#10142](https://github.com/omacom/omarchy/issues/10142), has the panel's one-second start retry wedging a Realtek RTL8761BU until the kernel resets it; the patch bounding that retry, [#10176](https://github.com/omacom/omarchy/pull/10176), was still open as of 4.0.4.

**The controller is genuinely suspended or wedged.** Omarchy ships `/etc/modprobe.d/omarchy-usb-autosuspend.conf` containing `options usbcore autosuspend=-1`, and [#12095](https://github.com/omacom/omarchy/issues/12095) shows it cannot take effect, because `usbcore` is built into the kernel. The per-device setting comes from a udev rule instead, so Intel controllers keep runtime suspending and BLE reconnects time out.

Worth knowing about the on and off path: 4.0.0 moved the remembered Bluetooth power state into the rfkill soft block, since BlueZ never persisted it. The 4.0.0 migration also reverts the old `AutoEnable=false` line in `/etc/bluetooth/main.conf`. On 3.x you got bluetui and a Waybar module instead of a Quickshell panel, so the stale panel fault does not exist there, though the wedged controller cases do.

## If that did not work

Pin the Intel controller on with a udev rule, using your own vendor and product IDs from `lsusb`:

```
ACTION=="add|bind|change", SUBSYSTEM=="usb", ATTR{idVendor}=="8087", ATTR{idProduct}=="0026", ATTR{power/control}="on"
```

Save that as `/etc/udev/rules.d/61-bluetooth-no-autosuspend.rules`. This is the rule jordanglean verified on [#12095](https://github.com/omacom/omarchy/issues/12095).

On ThinkPads and some Dells, turning Bluetooth off through the panel can cut USB power to the module rather than just soft blocking it, so the adapter vanishes from the bus entirely. [#7936](https://github.com/omacom/omarchy/issues/7936) documents the mechanism. On some models `rfkill unblock bluetooth` re-enumerates the module; on two X1 Carbons it did not, and what brought the radio back was rebinding the xHCI controller that owns the port: `echo -n 0000:00:14.0 > /sys/bus/pci/drivers/xhci_hcd/unbind`, wait a few seconds, then the same into `bind`, with your own PCI address from `lspci`. Expect the webcam and fingerprint reader on that controller to drop for a moment. Elsewhere only a suspend and resume, or a reboot, brings it back.

On T2 MacBooks with the BCM4377 combo chip, Bluetooth and suspend fail together, and the reporter on [#11264](https://github.com/omacom/omarchy/issues/11264) needed the Wi-Fi and Bluetooth modules unloaded before sleep and Wi-Fi reloaded about 15 seconds after wake, since reloading it immediately crashed the machine. See [/hardware/t2-mac/](/hardware/t2-mac/). A separate report, [#12120](https://github.com/omacom/omarchy/issues/12120), has a Broadcom controller failing its HCI reset after the 4.0.4 `linux-omarchy` kernel, with `Bluetooth: hci0: command 0x0c03 tx timeout` in the journal. There, reloading `btusb` reproduced the failure and only a full USB re-enumeration of the port, writing 0 then 1 to that device's `authorized` file under `/sys/bus/usb/devices/`, cleared it for the boot. Both were open and unfixed at the time of writing.

If Bluetooth audio specifically dies on resume, [#11280](https://github.com/omacom/omarchy/issues/11280) traces a WirePlumber crash in the PipeWire bluez plugin right after S3 resume. Systemd restarted the service on its own within a second, and the headset still failed to connect, so restarting WirePlumber by hand is unlikely to help. The fault is upstream in PipeWire and the thread records no workaround.

## Related

- [/hardware/bluetooth/](/hardware/bluetooth/) for controller by controller status
- [/hardware/suspend-sleep/](/hardware/suspend-sleep/) if the machine itself struggles to sleep or wake
- [/fix/quickshell-crashes-or-bar-missing/](/fix/quickshell-crashes-or-bar-missing/) if the whole bar is wrong, not just the Bluetooth part
- [/reference/commands/omarchy-bluetooth-power/](/reference/commands/omarchy-bluetooth-power/) for what the toggle actually runs
- The Omarchy manual's [Troubleshooting](https://omarchy.org/manual/troubleshooting/) chapter points at _Update > Hardware > Bluetooth_ as the first thing to try, which is the rfkill unblock in step 3

## Sources

- [Issue #7573: Bluetooth panel latches "Turned Off" when the adapter powers up after quickshell, disabling GUI pairing and the toggle](https://github.com/omacom/omarchy/issues/7573)
- [Issue #9561: Bluetooth bar toggle can remain visually off after resume while adapter is powered](https://github.com/omacom/omarchy/issues/9561)
- [Issue #10818: Bluetooth panel LE scan blocks reconnect of dual-channel BLE mice](https://github.com/omacom/omarchy/issues/10818)
- [Issue #12095: omarchy-usb-autosuspend.conf is a no-op; Intel Bluetooth controllers still autosuspend (BLE HID reconnect timeouts)](https://github.com/omacom/omarchy/issues/12095)
- [Issue #11936: Bluetooth agent stays stale after bluetoothd restarts](https://github.com/omacom/omarchy/issues/11936)
- [Issue #7936: omarchy-bluetooth-power off: type-wide rfkill block trips platform switches and removes the radio from the USB bus (ThinkPad/Dell)](https://github.com/omacom/omarchy/issues/7936)
- [Issue #11280: WirePlumber SIGSEGV in PipeWire Bluetooth plugin immediately after S3 resume](https://github.com/omacom/omarchy/issues/11280)
- [Issue #11264: MacBook Air 2020 (MacBookAir9,1, T2): Bluetooth never powers on at boot, and suspend always fails on brcmfmac D3 timeout](https://github.com/omacom/omarchy/issues/11264)
- [Issue #12120: Internal Broadcom Bluetooth controller fails HCI reset after linux-omarchy 7.2.5-3 update (MacBookPro11,4)](https://github.com/omacom/omarchy/issues/12120)
- [Issue #10142: Bluetooth panel: unbounded StartDiscovery retry wedges the controller and kills LE background scanning](https://github.com/omacom/omarchy/issues/10142)
- [PR #10176: Bound the Bluetooth panel's discovery retry](https://github.com/omacom/omarchy/pull/10176)
- [Omarchy manual: Troubleshooting](https://omarchy.org/manual/troubleshooting/)