What Is bluetoothd on Mac? It Hears 728 Beacons a Minute

bluetoothd is the macOS daemon that runs Bluetooth. It talks to the Bluetooth controller chip, keeps track of paired devices, handles connections for keyboards, mice and headphones, and hands Bluetooth Low Energy scan results to other parts of the system. On my Mac mini it has run for almost 26 days and used 27 minutes 38 seconds of CPU. That is 0.074% of one core, rank 43 of 686 processes, with 20 MB resident.

What made me look closer is that this Mac has nothing connected over Bluetooth. Three Apple peripherals are paired, a Magic Mouse, a Magic Keyboard and a Magic Trackpad, and all three show "Not Connected." The machine is headless. bluetoothd still never goes idle. Over the last 16 hours its chip counted about 728 Bluetooth advertisements a minute, day and night, from devices that are not mine.

The rig is a Mac16,10 (M4, 16 GB) on macOS 26.4.1 (25E253) with a Broadcom BCM_4388C2 controller on PCIe. Everything below was measured on 2026-10-24 as an admin user without sudo.

What bluetoothd is

$ ps -axo pid,user,etime,time,rss,comm | grep [b]luetoothd
  648 root  25-22:45:02  27:38.37  20064 /usr/sbin/bluetoothd

It is a system LaunchDaemon (/System/Library/LaunchDaemons/com.apple.bluetoothd.plist) running as root. The binary is 23.6 MB and universal (x86_64 and arm64e). The plist registers 15 Mach services, which are the doors other processes knock on. They include com.apple.server.bluetooth, com.apple.server.bluetooth.le.att.xpc, com.apple.BTAudioHALPlugin.xpc for Bluetooth audio, and com.apple.bluetooth.BTPacketLogger. If the daemon and agent split is new to you, LaunchAgent vs LaunchDaemon explains it.

A few smaller processes sit next to it. On this Mac they were:

Process	Runs as	CPU in 26 days	Role
bluetoothd	root	1,658 s (rank 43)	The daemon: controller, pairing, connections, LE scanning
audioaccessoryd	user	48 s (rank 180)	AirPods and Beats features
bluetoothuserd	user	0.2 s (rank 514)	Per-user helper
IOUserBluetoothSerialDriver	_driverkit	0.01 s	DriverKit serial-port driver

The role column is my reading of the plists, Mach service names and process names. Apple does not document these daemons.

What it does with nothing connected

I streamed bluetoothd's log at debug level for five minutes (10:33:43 to 10:38:43) and read its CPU time before and after. It used 0.33 CPU seconds, or 0.11% of a core, and wrote 4,204 log lines. 61% of them came from one category, Server.LE.Scan. It is scanning.

Once a minute the controller reports a line like this, and it shows the scale:

vseAdvStatsEvent - ver 2 duration 60 (secs) instance 0
  num ADVs [total 729 NonExtended 729 Extended 0]
  Ch [37 242 38 242 39 245] FailedOnAllCh 0

That is 729 advertisement packets heard in 60 seconds, spread evenly over the three BLE advertising channels (37, 38 and 39). This line is logged at Default level, so it stays on disk. The unified log on this machine keeps only about 17 hours, and in that window I found 960 of these reports from 18:40 yesterday to 10:39 today. The average was 728 a minute. Every hourly average fell between 723 and 741, and 03:00 looked the same as 21:00. That flatness suggests most of the packets come from devices that sit nearby all the time, not from people walking past. Over a day it adds up to roughly a million advertisements, and bluetoothd itself gets only a few of them.

The filtering happens in the chip. Every 21 seconds or so bluetoothd reprograms it: it resets the controller's advertisement matching rules, then sends new service UUIDs and new matching rules as vendor-specific commands. That happened 13 times in my five minutes. Each cycle also tried three commands the chip answered with not supported, 39 refusals in five minutes, none of them followed by an error. Only packets that match a rule are passed up. In five minutes that was 183 packets from 16 different random addresses, about 5% of the traffic.

Who it is scanning for

All 183 packets that reached bluetoothd carried Apple's company identifier, 4C 00. The byte after it is the message type, and the furiousMAC Continuity project has reverse-engineered those types:

Type	Meaning (per furiousMAC)	Packets	Addresses
0x12, length 2	Find My, short form	107	11
0x07	Proximity pairing (AirPods and similar)	19	2
0x12, length 25	Find My, full public key	15	2
0x0F	Nearby Action	14	2
0x0C	Handoff	10	2
0x10	Nearby Info	18	2

Find My frames are most of it. The full 25-byte form carries part of a rotating public key. A Mac that hears one can encrypt its own location with that key and upload it, so the owner of a lost device sees where it is. This is the crowd-sourced network Heinrich and colleagues described in "Who Can Find My Devices?". The furiousMAC repo documents the 25-byte form. I did not decode the 2-byte form, so I am only reporting how often it showed up.

The log also names the clients that asked for these scans. Counted by how often each appeared in the five minutes: locationd 219 times, searchpartyuseragent 48, bluetoothd itself 40, searchpartyd 16, accessibility.heard 16, and PerfPowerServices, useractivityd (Handoff), cloudpaird and tipsd 8 each. searchpartyd is the Find My daemon. Its side of the same traffic is in what is searchpartyd on Mac. One label is odd: 130 of the scan checks were tagged (FindMyNotOptedIn), and the Find My scan sessions kept running anyway. I don't know what that tag changes.

The rest of the noise is bluetoothd failing to decode other people's devices. Lines like Decrypt AccessoryStatus ADV failed: no key (13 of them) and No encryption key for the device Random ... appear because the packets are encrypted for their owners' iCloud accounts, not for this Mac.

Log volume

The world-readable logdata.statistics file in /var/db/diagnostics lists the top writers for every rotated log file. From 2026-10-01 to today it covers 55.46 GB of persisted log. bluetoothd wrote 353 MB of that, 0.64%, rank 15 of 399 processes. On a normal day it writes 16 to 18 MB (range 8.6 to 20.5 MB). That is not much on its own, but it is a cost the Mac pays for devices it is not using. For comparison, searchpartyd wrote 62 MB in the same period and audioaccessoryd about 1 MB.

High CPU, high memory, and "sudo pkill bluetoothd"

On this Mac the answer to "is bluetoothd using too much?" is no: 0.07% of a core and 20 MB after 26 days. The reports of trouble look different. One Apple Developer Forums poster on a 15-inch MacBook Air M2 with Sonoma 14.6.1 saw bluetoothd at 1.2 GB of RAM, growing over weeks without a restart and back to about 14 MB after one. Nobody replied. An older Apple Community thread reports the predecessor, blued, at 1.03 GB real memory with almost no CPU. I watched resident memory only. footprint refuses a root process without sudo, so I could not measure what Activity Monitor calls Memory.

The usual fix online is sudo pkill bluetoothd. I could not run it. Without sudo, even signal 0 fails:

$ pkill -0 -x bluetoothd
pkill: signalling pid 648: Operation not permitted

The plist explains why the daemon comes back afterwards, and it is not the reason people usually give. KeepAlive is {SuccessfulExit = false}. In man launchd.plist terms, launchd restarts it only after an exit with a non-zero status. If it exits cleanly on SIGTERM, something else has to relaunch it, and the likely candidate is the next client looking up one of its 15 Mach services. That last step is my inference from the plist, because I could not kill it to check. The fix itself does not always work. A Mac mini 2018 owner on Sequoia wrote that "sudo pkill bluetoothd ... did not help". Their mouse and keyboard came back only after they booted an old Mojave volume and used its hidden Bluetooth reset menu.

If bluetoothd really is busy, the five-minute log above suggests where to look first. Check whether a paired device keeps dropping and reconnecting, and whether the Mac sits in a room full of Apple devices. log stream --process bluetoothd shows which session is active. If you added a USB dongle, the list of chips bluetoothd will accept is in USB Bluetooth adapter for Mac.

FAQ

What is bluetoothd on Mac?

bluetoothd is the macOS system daemon that runs Bluetooth. It controls the Bluetooth chip, manages pairing and connections, and passes Bluetooth Low Energy scan results to services such as Find My, Handoff and location. It runs as root under launchd from /usr/sbin/bluetoothd. On a Mac mini that had been up for 26 days it used about 0.07% of one CPU core and 20 MB of resident memory.

Why is bluetoothd running when no Bluetooth devices are connected?

Because Bluetooth Low Energy scanning keeps going without connections. On a headless Mac mini with nothing connected, the Bluetooth controller heard about 728 advertisements a minute from nearby devices, and bluetoothd received about 5% of them after the chip's filters. Most were Apple Find My, Handoff and AirPods frames requested by locationd and the Find My daemons. It used about 0.1% of one CPU core while doing this.

Is it safe to run sudo pkill bluetoothd?

It stops the daemon and drops every Bluetooth connection, including a Bluetooth keyboard and mouse, so do it with a wired keyboard or over SSH. macOS starts bluetoothd again when it is needed. It is a common fix for stuck Bluetooth, but users report it does not always help. Removing and re-pairing the device, or restarting the Mac, are the next steps.

Measurements come from one Mac16,10 on macOS 26.4.1, read without sudo on 2026-10-24: the launchd plist and man launchd.plist, system_profiler SPBluetoothDataType, ps CPU totals for 686 processes, a five-minute log stream --process bluetoothd --level debug with CPU read before and after, 16 hours of the controller's per-minute vseAdvStatsEvent reports from log show, and 23 days of /var/db/diagnostics/logdata.statistics. Message types come from the furiousMAC Continuity project's reverse engineering, not from Apple. Nearby device addresses were counted, not kept. I did not test pkill, memory footprint or turning Bluetooth off. The memory and pkill reports are single user posts from 2009, 2024 and 2025.