The Spatial Awareness Engine
When you open Apple Maps on your Mac, or when Safari asks to use your current location to find a nearby coffee shop, your Mac is not using a dedicated GPS chip—because Macs do not have GPS hardware. Instead, macOS relies on a highly sophisticated spatial awareness daemon called CoreLocation (locationd).
CoreLocation determines your precise physical location by scanning the Wi-Fi environment. It activates the Wi-Fi radio, records the MAC addresses (BSSIDs) of every router in your vicinity, and sends that list securely to Apple’s massive global telemetry database. Apple replies with the exact GPS coordinates of those routers, allowing your Mac to instantly triangulate its position on a map.
To make this process fast and reduce network overhead, locationd maintains a massive local SQLite cache of recently seen Wi-Fi routers and their corresponding geographic coordinates. However, if this cache becomes corrupted, or if you move to a new apartment and bring your old Wi-Fi router with you, the cache breaks. The symptoms are unmistakable: you open Maps in New York City, but the blue dot stubbornly insists you are in Chicago (where your router used to be). Furthermore, the locationd process might get stuck in an infinite loop, consuming 100% of a CPU core as it frantically tries to resolve the conflicting data. To fix this, you must forcefully obliterate the CoreLocation cache via the Terminal.
Locating the Location Databases
Because CoreLocation handles highly sensitive geographic tracking data, the cache is strictly isolated. It is stored deep within the root-level /var/db/ directory, heavily protected by macOS System Integrity Protection (SIP) and standard UNIX permissions.
The specific cache resides in /var/db/locationd/.
Purging the Cache via Terminal
You cannot use Finder to access this directory. You must use the Terminal with elevated (sudo) privileges to violently stop the tracking daemon, release the file locks on the SQLite database, and perform a hard reset.
- Open the Terminal application.
- First, you must terminate the
locationddaemon. This instantly stops the runaway CPU usage and releases the locks on the database files:
sudo killall locationdPress Enter, type your Mac’s administrator password (the characters will remain invisible), and press Enter again.
- Next, navigate into the highly restricted database directory:
cd /var/db/locationd/- You must now aggressively delete the specific files that contain the cached geographic coordinates and the router triangulation data. Execute the following removal commands:
sudo rm -f clients.plist
sudo rm -rf Library/(Note: Depending on your exact version of macOS, the SQLite cache files might be named differently, but deleting the local Library subdirectory within locationd completely flushes the cached spatial data).
The Triangulation Reset
macOS is heavily dependent on launchd. The moment you executed the killall locationd command, the operating system realized the spatial awareness daemon had died and immediately respawned a fresh, uncorrupted instance of it in the background.
When the new locationd boots up, it will look inside /var/db/locationd/ and realize its cache is completely gone. It will generate a pristine, 0-byte database.
What happens next? The next time you open an app that requests your location (like Weather or Maps), the daemon will execute a completely fresh Wi-Fi sweep. It will query Apple’s servers using your current, real-time RF environment, completely ignoring the old, corrupted data. The blue dot will instantly snap to your correct physical location in New York City, and the crippling 100% CPU drain will be permanently resolved.