Cannot get WiFi SSID inside launchctl agent

On recent versions of macOS a program needs the Location privilege (from System Settings > Privacy & Security) to access SSID information. It should be feasible for a launchd agent to get that — unlike, say, a launchd daemon — but it’s not without its challenges. My usual advice here is:

1. Install the from a container app using SMAppService. This ensures that the system understands the relationship between the app and the agent.
2. Request the Location privilege in the container app.
3. In the agent, confirm that you have the Location privilege before attempting to do anything with Core WLAN. There’s a new-fangled way to do this but I tend to rely on the old ways.

I’ve run through this process for other privileges and it works a treat. 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. But give it a whirl and lemme know how you get along.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks again for your guidance. I’m following up with concrete implementation details and current repro logs because we still cannot read SSID via CoreWLAN from our agent process.

Environment:

macOS 26.3 (build 25D125)
Xcode 26.2 (17C52)
Wi-Fi interface: en0
Agent bundle ID: com.acme.SSIDInspector.Agent
App bundle ID: com.acme.SSIDInspector
How we launch the agent:

We use SMAppService.agent(plistName:) from the main app. Embedded LaunchAgent plist path in app bundle: com.acme.SSIDInspector.Agent.plist Plist details:

Label = com.acme.SSIDInspector.Agent
BundleProgram = Contents/Resources/SSIDInspectorAgent.app/Contents/MacOS/SSIDInspectorAgent
MachServices includes com.acme.SSIDInspector.Agent
RunAtLoad = true, KeepAlive = true
We call register()/unregister() on SMAppService, and use XPC (NSXPCConnection to mach service) to verify the agent is running/reachable.

Privacy/authorization setup:

Agent Info.plist usage strings are present:

• NSLocationAlwaysUsageDescription
• NSLocationUsageDescription
• NSLocationWhenInUseUsageDescription

Agent entitlement includes:

• com.apple.security.personal-information.location = true

Agent requests location authorization via CLLocationManager.requestAlwaysAuthorization().

On startup we consistently see: notDetermined -> authorizedAlways one warmup location update received and stopped. Observed CoreWLAN behavior:

In the agent process, CWWiFiClient.shared().interface()?.ssid() remains nil. At the same time, CoreWLAN interface data indicates association (BSSID/channel present), so our diagnostic path marks this as redacted/unavailable SSID. Representative log sequence (2026-02-26 13:16:02 local):

location authorization changed: authorizedAlways
location authorization granted; CoreWLAN SSID reads should be eligible
corewlan summary currentInterface=en0 currentSSID=nil interfaces=en0:ssid=nil
probe source corewlan returned redacted SSID marker
observed SSID becomes <SSID Redacted> (not actual SSID)
Important note:

The remaining issue is specifically CoreWLAN SSID visibility in this LaunchAgent context.

Question: Given this setup, is there any additional requirement/restriction for SSID visibility when the process is a background LaunchAgent registered via SMAppService (as opposed to a foreground app process)?

If helpful, I can provide a minimal reproducible sample project with this exact architecture.

Thank you.

“Also, in System Settings > Privacy & Security > Location Services, we consistently see duplicate SSIDInspector entries (one with a warning icon) plus SSIDInspectorAgent. This suggests stale or conflicting TCC identity records. We are resetting TCC and re-registering via SMAppService, but wanted to confirm whether duplicate/stale TCC rows can affect CoreWLAN SSID visibility for a LaunchAgent process.”

Disregard that last remark about duplicate tcc entries. I cleaned everything out manually.

Thanks for all the extra info. I have a couple of comments.

I cleaned everything out manually.

How exactly?

I try to avoid testing this stuff on my development machine because the constant build / run / debug cycle exposes edge cases that are rarely seen on normal user machines. I explain my standard approach for this sort of testing in Testing a Notarised Product. It’s discussing a different technology, but the general approach will work here.

IMPORTANT Most VM apps don’t virtualise Wi-Fi, so you won’t be able to test the Core WLAN side of this. But you can test the Core Location side, and I think that’s what’s key here.

Agent requests location authorization

Have you tried requesting location authorisation from the container app? That should work because the app is just a normal GUI application. And I’m hoping that this authorisation will then be available to your agent because the app is the responsible code for your agent.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"