fix(helper): pump run loop for CLLocationManager auth before scan (#45)

Real root cause of the macOS 26 install hang. The v1.0.3 fix added
disclaim-responsibility + CLLocationManager.startUpdatingLocation()
+ Thread.sleep(0.3) to runScanAndDumpJSON. The disclaim hop and
the manager init are correct; the Thread.sleep was wrong.

Thread.sleep does NOT pump the run loop. CLLocationManager's
delegate-callback handshake with locationd never actually
completes inside a short-lived CLI subprocess. CoreWLAN's macOS
26 redaction gate checks whether the process is a *registered*
location consumer — not just authorised — so scans came back
redacted (ssid/bssid null) even when the bundle's TCC grant was
in place. The bundle GUI sees authorizationStatus as granted
because that's a synchronous read of cached state; the redaction
gate is the stricter check.

This kept the user stuck at "需要以下权限：- 定位服务" through
v1.0.3 / v1.0.4 / v1.0.5 even after clicking Allow on every
prompt.

Fix: new LocationAuthProbe : CLLocationManagerDelegate that flips
a flag when `locationManagerDidChangeAuthorization` resolves
status to non-.notDetermined. The scan subcommand pumps
`RunLoop.current.run(mode:.default, before:…)` in 50ms slices,
exiting as soon as the callback fires (typically <100ms when the
grant is already in TCC.db) or after a 2s timeout. Only then
does scanForNetworks run. Same pattern as the existing
runBluetoothStatusProbe.

Verified locally end-to-end:
- helper/build.sh rebuilds → new cdhash 6e74d56e...
- user grants Location on the new cdhash via `open helper/...`
- 3 cold-start subprocess scans (helper GUI killed between runs
  to defeat warm-cache effects) → 100% unredacted rows each run

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: chenchaoyi

CHANGELOG.md

@@ -9,6 +9,37 @@ the project follows [Semantic Versioning](https://semver.org/) where
 practical. The leading `v0.x` line is allowed to break minor
 behaviours between releases.
 
+## [1.0.6] — 2026-05-13
+
+The v1.0.3 → v1.0.5 chain attempted to fix CoreWLAN scan
+redaction under install.sh-installed helpers via
+disclaim-responsibility + `CLLocationManager.startUpdatingLocation()`
++ `Thread.sleep(0.3)`. The disclaim hop and the manager init are
+necessary but the third piece was wrong: `Thread.sleep` does not
+pump the run loop, so `CLLocationManager`'s delegate-callback
+handshake with `locationd` never actually completes inside the
+short-lived CLI subprocess. CoreWLAN's redaction gate on macOS 26
+checks whether the calling process is a *registered* location
+consumer (not just an authorized one), so scans came back redacted
+even when the bundle's TCC grant was in place.
+
+This kept the user stuck at "需要以下权限：- 定位服务" through
+v1.0.3 / v1.0.4 / v1.0.5 even after clicking Allow on the popup.
+
+### Fixed
+- **`runScanAndDumpJSON()` pumps the run loop until the location
+  authorization callback fires.** New `LocationAuthProbe` delegate
+  signals when `locationManagerDidChangeAuthorization` resolves to
+  a non-`.notDetermined` state. The scan subcommand now runs
+  `RunLoop.current.run(mode:.default, before:…)` slices of 50 ms
+  each, exiting as soon as the callback lands (typically <100 ms
+  on a freshly-granted bundle) or after a 2 s timeout. Only then
+  does `scanForNetworks` get called. Mirrors the existing
+  `runBluetoothStatusProbe` pattern.
+- Verified locally end-to-end: 3 cold-start subprocess scans
+  (helper GUI killed between runs to defeat warm-cache effects)
+  return 100% unredacted rows.
+
 ## [1.0.5] — 2026-05-13
 
 User on macOS 26 installed v1.0.4 via the one-liner and ended up

docs/zh/CHANGELOG.md

@@ -8,6 +8,32 @@
 [Semantic Versioning](https://semver.org/)。`v0.x` 阶段允许破坏性的次要
 行为变更。
 
+## [1.0.6] — 2026-05-13
+
+v1.0.3 → v1.0.5 一路上想修 install.sh 安装路径下 CoreWLAN scan 数据
+被屏蔽的问题，做法是「disclaim 责任继承 + `CLLocationManager.start
+UpdatingLocation()` + `Thread.sleep(0.3)`」。disclaim 和 manager 初
+始化都是必要的，第三块错了：`Thread.sleep` 不会 pump run loop，所
+以 `CLLocationManager` 跟 `locationd` 的 delegate 回调握手在 CLI
+子进程的短生命周期里根本完不成。macOS 26 上 CoreWLAN 的屏蔽门看
+的是「调用方进程是不是已注册的 location 消费者」（不是「是否被授权」），
+所以即使 bundle 的 TCC 授权已经在了，scan 出来还是 null。
+
+用户从 v1.0.3 一路被卡到 v1.0.5，点了 Allow 弹窗也无解，就是这个
+原因。
+
+### 修复
+- **`runScanAndDumpJSON()` 现在真正 pump run loop 等
+  `CLLocationManager` 授权回调**。新加 `LocationAuthProbe` delegate，
+  在 `locationManagerDidChangeAuthorization` 回调里把 status 从
+  `.notDetermined` 翻转出来时打标记。scan 子命令以 50 ms 为粒度跑
+  `RunLoop.current.run(mode:.default, before:…)`，回调一落地立刻退
+  出（已授权的 bundle 上通常 <100 ms），或 2 秒超时兜底。完成后才
+  调 `scanForNetworks`。模式对齐已有的
+  `runBluetoothStatusProbe`。
+- 本地端到端验证：3 次冷启动 subprocess scan（每次先 kill helper
+  GUI 防止 warm-cache 干扰）全部返回 100% 解屏蔽行。
+
 ## [1.0.5] — 2026-05-13
 
 macOS 26 用户走一行 installer 装 v1.0.4 之后，helper bundle 的

helper/Sources/diting-tianer/main.swift

@@ -53,43 +53,101 @@ import IOBluetooth
 // CLI mode: scan
 // ---------------------------------------------------------------------
 
+/// Probe-only CLLocationManager delegate used by `runScanAndDumpJSON`
+/// to wait until the location authorization state has been determined
+/// (i.e. CoreLocation's TCC handshake with `locationd` has run and
+/// landed) before we let CoreWLAN run its redaction check. Without
+/// waiting on the delegate, CoreWLAN sees a CLLocationManager that
+/// has only been `startUpdatingLocation`'d but never received a
+/// state callback — and treats the process as having no active
+/// location session, which is what macOS 26 uses to gate
+/// CWNetwork.ssid / .bssid.
+final class LocationAuthProbe: NSObject, CLLocationManagerDelegate {
+    private(set) var statusResolved = false
+    private(set) var lastStatus: CLAuthorizationStatus = .notDetermined
+
+    func locationManagerDidChangeAuthorization(_ manager: CLLocationManager) {
+        lastStatus = manager.authorizationStatus
+        if manager.authorizationStatus != .notDetermined {
+            statusResolved = true
+        }
+    }
+
+    // Pre-Catalina spelling — kept for completeness; macOS calls one of
+    // these two depending on SDK target.
+    func locationManager(_ manager: CLLocationManager,
+                         didChangeAuthorization status: CLAuthorizationStatus) {
+        lastStatus = status
+        if status != .notDetermined {
+            statusResolved = true
+        }
+    }
+}
+
 func runScanAndDumpJSON() -> Never {
-    // macOS 14.4+ gates CWNetwork.ssid / .bssid behind Location Services
-    // at the calling process level — having the bundle's TCC grant on
-    // disk is not enough. Two things have to be true at scanForNetworks
-    // time:
+    // macOS 14.4+ (and tighter on 26) gates CWNetwork.ssid / .bssid
+    // behind Location Services at the calling process level. Having
+    // the bundle's TCC grant on disk is not enough on its own — three
+    // things have to be true at scanForNetworks time:
+    //
+    //   1. The TCC subject seen by macOS is the helper bundle (not
+    //      the terminal that launched us). Inherited responsibility
+    //      from Terminal → diting → diting-tianer breaks this on
+    //      macOS 26 — tccd attributes the request to Terminal, which
+    //      has no NSLocationUsageDescription, and CWNetwork redacts
+    //      ssid / bssid silently. The fix is to disclaim our parent
+    //      so we become our own responsible process, same hop the
+    //      ble-scan subcommand has done since v0.5.0.
     //
-    //   1. The TCC subject seen by macOS is the helper bundle (not the
-    //      terminal that launched us). Inherited responsibility from
-    //      Terminal → diting → diting-tianer breaks this on macOS 26 —
-    //      tccd attributes the request to Terminal, which has no
-    //      NSLocationUsageDescription, and CWNetwork redacts ssid /
-    //      bssid silently. The fix is to disclaim our parent so we
-    //      become our own responsible process, same hop the ble-scan
-    //      subcommand has done since v0.5.0.
+    //   2. A CLLocationManager exists in this process AND has had
+    //      its authorization status callback fire. This is the
+    //      subtle bit: macOS treats a CLLocationManager that has
+    //      only been `startUpdatingLocation`'d (no delegate
+    //      callback yet) as "not yet a location-services consumer"
+    //      and CoreWLAN still redacts. The fix is to pump the run
+    //      loop until `locationManagerDidChangeAuthorization` fires,
+    //      which means CoreLocation has done its TCC handshake with
+    //      locationd and the process is now a recognised consumer.
     //
-    //   2. A CLLocationManager has called startUpdatingLocation() in
-    //      this process. The bundle grant alone isn't enough; CoreWLAN
-    //      checks for an active location signal at the moment of
-    //      scanForNetworks(). We init the manager, kick it, hold a
-    //      reference for the lifetime of the function so the runtime
-    //      can't release it before the scan call hits CoreWLAN.
+    //   3. The CLLocationManager reference stays alive across the
+    //      scanForNetworks() call so the runtime doesn't drop the
+    //      consumer registration mid-scan.
     //
-    // The earlier code comment claiming CoreLocation was "more lenient"
-    // than CoreBluetooth was wrong; CoreWLAN on macOS 26 enforces both.
+    // The earlier code comment claiming CoreLocation was "more
+    // lenient" than CoreBluetooth was wrong; CoreWLAN on macOS 26
+    // enforces all three. The v1.0.3 fix attempted only (1) + (3) +
+    // a Thread.sleep — but Thread.sleep doesn't pump the run loop,
+    // so (2) was missed and the scan still came back redacted on
+    // freshly-installed bundles. Mirror the existing bluetooth-status
+    // pattern: real run-loop pump, real delegate callback wait.
     if ProcessInfo.processInfo.environment[kDisclaimEnv] == nil {
         reExecWithDisclaimedResponsibility()
     }
 
     let locationManager = CLLocationManager()
+    let probe = LocationAuthProbe()
+    locationManager.delegate = probe
     locationManager.requestWhenInUseAuthorization()
     locationManager.startUpdatingLocation()
-    // Brief settle so CoreLocation's TCC registration lands before
-    // CoreWLAN inspects it. Empirically ~50ms is enough on M-series
-    // Macs; 300ms gives headroom on slower hardware without making
-    // the user wait an obvious extra beat.
-    Thread.sleep(forTimeInterval: 0.3)
-    _ = locationManager  // hold the reference until the scan returns
+
+    // Pump the run loop until the authorization callback fires or a
+    // 2-second timeout elapses. The callback only fires after
+    // CoreLocation has fully registered with locationd, which is what
+    // CoreWLAN's redaction gate checks for. Each `run(until:)` slice
+    // returns control briefly so we can re-check the probe flag and
+    // exit early once authorization is resolved — usually within ~50ms
+    // when the grant is already in TCC.db.
+    let deadline = Date(timeIntervalSinceNow: 2.0)
+    while !probe.statusResolved && Date() < deadline {
+        RunLoop.current.run(mode: .default,
+                            before: Date(timeIntervalSinceNow: 0.05))
+    }
+    // Proceed regardless of probe outcome. If authorization is still
+    // .notDetermined after 2 s (TCC grant genuinely missing), the
+    // scan will return redacted rows — same end state as before, just
+    // not slower than necessary. Hold the manager reference past the
+    // scan call so the consumer registration doesn't get released.
+    _ = locationManager
 
     let client = CWWiFiClient.shared()
     guard let iface = client.interface() else {

pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "diting"
-version = "1.0.5"
+version = "1.0.6"
 description = "macOS terminal listening post for Wi-Fi, BLE, link health, and the RF environment — your Mac hears more than it tells you"
 readme = "README.md"
 license = "MIT"