How to audit your launcher's network activity on macOS

Your launcher is the app you press more times a day than any other. It has Accessibility permission, Full Disk Access, and a foreground process that runs constantly. If it phones home — to log usage, to fetch updates, to sync settings, to call an AI endpoint — it does so dozens of times an hour, in your face, in the background.

Most launcher users have no idea what their launcher sends, where, and how often. This post walks through three ways to find out: the easy way (Little Snitch UI), the free way (lsof and nettop from Terminal), and the thorough way (Wireshark with a TLS proxy). All three work in 2026 on macOS Tahoe 26.

The goal is not paranoia. The goal is informed choice. Once you can see what your launcher is doing, you can decide whether to keep it, configure it, or replace it.

Why you should care

Three concrete reasons:

Energy. A launcher that sends an analytics ping every 30 seconds wakes the radio, drains battery, and contributes to network noise on shared connections.
Privacy. If you do not know what data the launcher sends, you cannot evaluate whether the privacy policy you skimmed actually matches the behavior.
Reliability. A launcher whose UI freezes when its analytics endpoint is slow is a launcher you do not want when your Wi-Fi flakes.

The audit takes 15 minutes for the easy variants, 1-2 hours for the deep one. Either is worth doing once.

Method 1: Little Snitch (easiest, paid)

Little Snitch is the macOS firewall most power users adopt. It is paid (currently around $59 for a license) and worth it for this kind of work.

Install Little Snitch. Open the Network Monitor (Little Snitch Mini also includes this). Filter by process name — e.g., Raycast, Alfred, Spotlight, or whichever launcher you use.

You will see:

Every domain the launcher contacts, with timestamps.
Bytes sent and received per connection.
A graph of network activity over time.

Run the launcher for an hour of normal use with Little Snitch capturing. At the end, the picture is clear: maybe two domains for update checks, maybe a dozen for AI calls if you use those features, maybe a steady stream of analytics if the launcher phones home.

A specific check: open the launcher and immediately quit it. If you still see network activity for the launcher's process, it has a background updater or analytics flusher that runs even when you do not. That is fine if you knew about it; surprising if you did not.

Method 2: `lsof` and `nettop` (free, CLI)

If you do not want to install Little Snitch, macOS ships two tools that give you most of the same picture from Terminal.

`lsof` for a point-in-time snapshot

# Show open network connections for the launcher process
lsof -i -P -n -p "$(pgrep -i raycast)"

# Same for Lume
lsof -i -P -n -p "$(pgrep -i lume)"

# All network connections, by app
lsof -i -P -n | grep -i raycast

Output shape (abbreviated):

COMMAND   PID  USER   FD   TYPE  DEVICE  NAME
Raycast  1234  alice  17u  IPv4  ...     192.168.1.10:51234->raycast.com:443

You see exactly which remote endpoint the launcher has open right now. Run lsof several times across an hour and you build up a list of all the endpoints the launcher contacts.

`nettop` for a live feed

# Live network activity per process
nettop -p Raycast

# All processes, traffic over time
sudo nettop -L 1

nettop is a built-in monitor that shows bytes-in and bytes-out per second, per process, per connection. Run it in one Terminal window, use your launcher in the foreground, and watch the bytes flow.

Specific things to look for:

Constant background traffic when you are not using the launcher. Common reason: telemetry. Less common but possible: remote settings replication.
A burst on launcher open. This is normal — update checks, AI key validation. Worth knowing the size.
Traffic to AI endpoints when you have not used AI features. Sometimes "preload" connections are made to reduce latency on first use. Sometimes it is overreach.

`pfctl` to confirm

If you want to test "what would happen if this endpoint were blocked," you can use macOS's built-in pfctl packet filter:

# Create a rule file
sudo tee /etc/pf.anchors/launcher_block.conf <<'EOF'
block drop out quick proto tcp from any to <suspicious-domain>
EOF

# Load it
sudo pfctl -a launcher_block -f /etc/pf.anchors/launcher_block.conf
sudo pfctl -e

Less convenient than Little Snitch but free and built-in.

Method 3: Wireshark + mitmproxy (deepest, takes effort)

If you want to know not just where the launcher sends data but what it sends, you need a TLS proxy. The standard tool is mitmproxy:

brew install mitmproxy

The setup is a real project:

Install mitmproxy's CA certificate in macOS Keychain and trust it.
Configure system proxy to point at localhost:8080.
Run mitmproxy and watch HTTPS requests in cleartext.

The catch: many modern apps use certificate pinning, which defeats mitmproxy. The launcher might silently fail or refuse to make any HTTPS request. If pinning is in use, you cannot inspect the contents without binary-patching the app — not a casual undertaking.

If the launcher does not pin certificates, you will see every request body, header, and response. This is the ground truth for "what does this app send."

For most users, this depth is overkill. Method 1 or Method 2 gives a clear picture of whether and how often the launcher phones home, which is the question most worth answering.

A specific audit checklist

Run this list against your launcher of choice. Each step is 1-2 minutes:

At launch: open the launcher with a network monitor capturing. Note every domain contacted in the first 10 seconds.
At idle: leave the launcher running but unused for 5 minutes. Note any traffic.
On a search query: type a search query that has only local matches. Note any traffic during/after.
On a setting change: change one preference. Note whether the change syncs anywhere.
On AI use (if applicable): run an AI command. Note the endpoint and payload size.
On quit: quit the launcher. Note any flush-on-exit traffic.

The result is a profile: this launcher contacts these N domains, in these scenarios, with this approximate volume. That profile is the basis for an informed keep/configure/replace decision.

Common findings

A short list of patterns I have seen across audits in 2025-2026:

Update checks at launch. Universal. One request to a check-for-update endpoint, returns a version string. Almost always fine.
Analytics ping at launch. Common. Sends app version, OS version, sometimes a randomized install ID. Usually fine; sometimes more granular than disclosed.
AI endpoint preload. Some launchers open a connection to their AI endpoint at startup. Lowers first-query latency at the cost of a constant TLS connection.
Settings sync at startup. Sync-equipped launchers will fetch settings on launch. Volume small, but it is a privacy-relevant exchange.
Recurring telemetry every N minutes. Less common, but a few launchers do this. Worth noticing.
Plugin-store browsing while idle. A launcher that periodically fetches its plugin catalog. Surprising the first time you see it.

None of these are inherently bad. All of them are worth knowing about.

What to do with the findings

Three reasonable responses, depending on what you find and how you feel:

Configure

Most launchers expose telemetry and analytics toggles in preferences. Open them, disable what you can. Re-run the audit and verify the traffic actually stopped — sometimes the toggle reduces volume rather than eliminating it.

Block

Little Snitch can block specific domains while letting others through. If the launcher's update check is fine but its analytics endpoint annoys you, block the analytics endpoint. The launcher will retry occasionally; otherwise unaffected.

Replace

If the launcher's network behavior fundamentally clashes with what you want — a sync-first launcher when you want local-first, a chatty launcher when you want quiet — replace it. The keyboard muscle memory for ⌘Space survives a launcher swap. The full replacement case for privacy-first users: When a launcher syncs to a remote server, the real price.

Lume is built to make this audit boring. Local-first, no account, no telemetry. The audit on Lume returns roughly: an update check at launch, optionally the local Ollama endpoint when you use AI, and nothing else. If you want the audit to show "no network traffic when idle," that is the design target.

Raycast and Alfred have their own profiles. Raycast contacts more domains than Alfred because more of its features are cloud-backed; Alfred contacts almost nothing if you have not configured an AI workflow. Both are honest about this in their docs.

Re-audit after every major update

Two cases warrant re-running the audit:

After a launcher version bump. Vendors add features (and analytics) between releases. The audit from six months ago may be stale.
After a macOS major release. Sometimes a new macOS version forces a launcher to do new things (re-request permissions, re-validate signatures). Worth checking that none of those involve new endpoints.

Twenty minutes once a quarter. Not bad insurance for the most-used app on your Mac.

The broader principle

The reason this matters is not really about launchers specifically. It is that the apps you trust the most — the ones you give Accessibility permission, the ones that read every keystroke, the ones that mediate every search — are exactly the apps whose network behavior you should know.

A launcher is a magnifying glass. A privacy-leaky launcher leaks privacy in the part of your workflow where leaks hurt most. A reliable launcher with quiet network behavior is one of the cleanest force-multipliers for an offline-first or privacy-first setup.