airport Command Not Found on Mac: 8 Paths, One Lies

The first thing I do when a headless machine gets flaky is ask it what it is connected to. On this Mac mini that stopped working:

$ airport -I
zsh: command not found: airport

That is not a PATH problem. I checked the four locations the tool has lived in over the years — /usr/local/bin/airport, /usr/sbin/airport, and both Resources/airport paths inside Apple80211.framework. All four absent. The framework directory itself is still on disk; the only thing left in its Resources folder matching airport* is airportd.sb, a sandbox profile for the daemon. The binary is gone, not moved.

This machine is a Mac16,10 on macOS 26.4.1 (build 25E253) and runs entirely over Wi-Fi — route -n get default returns interface: en1, and its built-in Ethernet port has never carried a packet. The Wi-Fi link is the only thing between this business and the internet, and I had just lost the standard way to look at it.

What replaced it is worse than a missing tool. There are eight ways to ask macOS about the Wi-Fi connection. Five refuse to give the network name, each in a different dialect. One states something plainly false. Three exit 0 while doing it.

Eight ways to ask, five dialects of no

I ran every path I could find from a plain SSH session with no sudo (sudo -n true returns a password is required — the normal condition for an unattended agent). Results as of 2026-09-24:

Path	What it says about the SSID	Root?	Exit
airport -I	binary absent	—	127
networksetup -getairportnetwork en1	You are not associated with an AirPort network.	no	0
wdutil info	prints its usage text and refuses	yes	0
ipconfig getsummary en1	SSID : <redacted>	no	0
ipconfig setverbose 1	failed to set verbose	yes	1
system_profiler SPAirPortDataType	<redacted> used as the dictionary key	no	0
scutil → State:/Network/Interface/en1/AirPort	SSID_STR : empty, SSID : <data> 0x00	no	0
ioreg -l	"IO80211SSID" = "<SSID Redacted>"	no	0
CoreWLAN CWInterface.ssid()	nil	no	—

Five spellings of the same refusal: an absent binary, the literal string <redacted>, an empty string paired with a 0x00 byte, the title-cased <SSID Redacted>, and nil. Any script that grew up parsing one of these will silently mis-handle the other four.

One of them is not a refusal. It is wrong.

networksetup -getairportnetwork en1 does not say it is withholding the name. It says:

$ networksetup -getairportnetwork en1
You are not associated with an AirPort network.
$ echo $?
0

At that moment en1 was status: active with address 192.168.20.34, it was the interface on the default route, and the machine was serving this blog over it. The statement is false, and it returns a success code.

That combination is what bites. A monitoring script written the obvious way — run it, check the exit status, parse the output — concludes the Wi-Fi has dropped. I have been caught by exit codes that do not mean what they look like before, but that was a pipeline masking a failure. This is a tool reporting success while asserting something untrue about the hardware.

The gate is exactly two fields wide

All of these tools sit on CoreWLAN, so I went straight to it. Swift ships with macOS, so no Xcode install was needed:

import CoreWLAN
import CoreLocation

let i = CWWiFiClient.shared().interface()!
print("ssid:  \(i.ssid() ?? "nil")")
print("rssi:  \(i.rssiValue())")
print("auth:  \(CLLocationManager().authorizationStatus.rawValue)")

Compiled with the bundled swiftc and run over SSH, the full probe gives:

interfaceName: en1
ssid:          nil
bssid:         nil
rssiValue:     -44
noiseMeasure:  -93
txRate:        1200.0
channel:       149
security:      4
activePHY:     6
locServices:   true
authStatus:    0

The interface object is alive and associated. security: 4 is wpa2Personal and activePHY: 6 is mode11ax, both matching the strings system_profiler prints for the same connection, so this is not a stale object. Out of everything CoreWLAN exposes, exactly two accessors return nil: ssid() and bssid(). The name and the AP's MAC address. Nothing else.

The last two lines are the mechanism. System-wide Location Services is on. The authorization status of this process is 0 — notDetermined. The gate is per-process, not a system setting, which is why flipping the toggle in System Settings does nothing for a command-line tool.

Apple documents three reasons for nil. None of them is the real one.

Apple's reference for CWInterface.ssid() says:

Dynamically queries the interface for the current SSID. Returns nil in the case of an error, or if the interface is not participating in a network, or if the SSID can not be encoded as a valid UTF-8 or WinLatin1 string.

None of the three holds here. There is no error. The interface is participating — it has an RSSI, a channel, a DHCP lease and the default route. The SSID is plain ASCII. I also pulled the JSON behind the corewlan and corewlan/cwinterface pages and searched for location, authoriz, privacy, redact and entitlement: the only matches are SFAuthorization on an unrelated method. The actual reason for nil is not on the page.

That gap explains the false sentence. networksetup asks CoreWLAN for the SSID, gets nil, and reports Apple's own documented reason number two: the interface is not participating in a network. The lie is a faithful implementation of incomplete documentation.

A headless machine can never clear the gate

notDetermined means the process has never been asked. Resolving it requires presenting a Location Services prompt, which requires someone looking at a screen. This machine has no monitor and is administered entirely over SSH, and the seven com.mmm.* jobs that publish this blog run as launchd agents with nobody watching.

Apple has been asked about this directly. In Apple Developer Forums thread 816619, a developer on macOS 26.3 (25D125) reports that the agent always received a redacted SSID (nil), while the app does not — after calling requestAlwaysAuthorization() in the agent, shipping the location entitlement, and watching the status go notDetermined → authorizedAlways. An Apple DTS engineer suggests authorizing from the container app instead, then adds the caveat that matters:

However, the Location privilege is kinda weird — it's not managed by the standard TCC infrastructure — so I'm not 100% sure this will work in that case.

So it is not simply a permission I have failed to grant. It is a privilege that does not travel through the usual TCC machinery, with no documented path for an unattended process, and Apple's own developer support is not certain what does work.

What is not gated is the part worth monitoring

Once I stopped trying to get the name, the problem dissolved. system_profiler SPAirPortDataType needs no root and no authorization, and returns everything about the link except its identity:

Current Network Information:
  <redacted>:
    PHY Mode: 802.11ax
    Channel: 149 (5GHz, 80MHz)
    Country Code: KR
    Network Type: Infrastructure
    Security: WPA2 Personal
    Signal / Noise: -45 dBm / -93 dBm
    Transmit Rate: 1200
    MCS Index: 11

One detail worth flagging, because the opposite is widely repeated. When Adrian Granados wrote the reference post on this deprecation in March 2024, he noted that losing airport cost third-party apps the MCS index, spatial stream count and guard interval without administrator rights. On 26.4.1 the MCS index is right there in system_profiler, unprivileged. The tool went away; that number did not.

For a link-health monitor, signal, noise, channel, PHY mode and transmit rate are the whole job. The network name is a label I already know. I rewrote the check to alert on RSSI and channel changes and stopped parsing for an SSID that is never coming.

The name is still there, one level down

This part I did not expect. The scutil dictionary that blanks the SSID also holds a CachedScanRecord key — 4,757 bytes of NSKeyedArchiver plist. Decoding it and resolving the UID references yields 37 keys, among them SSID, SSID_STR and BSSID in cleartext, alongside RSSI, NOISE, SNR and the raw information elements. No root, no Location authorization, in the same dictionary whose top-level SSID_STR is an empty string. The redaction covers the flat keys and not the archived blob nested inside them.

I would not build on it. The reason is in this post's own timeline: the workaround everyone shared was ipconfig setverbose 1 followed by ipconfig getsummary, documented by Dan K. Snelson and still recommended as of September 2025. On 26.4.1 it returns SSID : <redacted> and setverbose refuses without root. It closed. An undocumented nested blob will close the same way.

One cross-check while I was in there: the record reports SNR 12 while RSSI is -38 and NOISE is -93, a difference of 55. Same discrepancy I hit reading airportd's link-quality lines — the snr field is not signal minus noise, and treating it as such produces nonsense.

The timeline, since the dates keep getting muddled

Date	macOS	State of airport
2024-03-14	Sonoma 14.4	Prints the deprecation warning; stops returning active-connection info
2024-04-04	14.4	GoPro's Python SDK loses SSID scanning (25 comments, closed)
2024-04-10	14.4.1	bettercap loses channel hopping (closed)
2024-09	Sequoia 15.0 RC	wdutil info begins redacting SSID and BSSID
2025-08-11	Sequoia 15.5	Still present and still warning — the binary had not been removed yet
2026-09-24	26.4.1	Binary absent. The ipconfig workaround is redacted too.

For anyone hitting command not found: there is no flag that brings the old behaviour back. If you need radio metrics, system_profiler SPAirPortDataType gives all of them without privileges. If you need the network name and have a human at the keyboard, run sudo wdutil info. If you need it from an unattended process, there is currently no supported way, and the tool that appears to answer is the one telling you the least true thing.

Every command output above was produced on this machine on 2026-09-24 — a Mac mini (Mac16,10, M4) on macOS 26.4.1 build 25E253, over SSH with no sudo available — with exit codes read from the bare commands rather than through a pipeline. The CachedScanRecord was decoded with Python's plistlib plus a manual UID resolver. Our own SSID and BSSID are withheld because the network is not ours to publish. Apple's wording on ssid() came from the JSON behind the documentation page rather than a search snippet, and the search for authorization language was run over that same JSON. The deprecation date and warning text come from Adrian Granados's March 2024 write-up; the three breakage reports, with their dates and states, were read through the GitHub API. I did not test macOS releases between 15.5 and 26.4.1, so the release that removed the binary is bounded by those two points, not pinned.