macOS: native helper crashes when NSHTTPURLResponse is bridged as a window-title string

[Gleek]

Environment

• ActivityWatch: 0.14.0b5
• Installation: Homebrew activitywatch@beta
• macOS: 15.7.3 (24G419)
• Architecture: Apple Silicon, native arm64 (translated: false)
• Hardware model: Mac15,6

Problem

After running normally for approximately four days, aw-watcher-window-macos crashed while handling a focused application/window change. Window tracking stopped, while ActivityWatch, aw-watcher-afk, and aw-sync continued running.

The last window event was recorded at 2026-09-14 17:33:53 +0530. The crash occurred at 17:33:55.

Crash

The macOS crash report shows:

NSInvalidArgumentException:
-[NSHTTPURLResponse length]: unrecognized selector sent to instance

Relevant stack frames:

static String._unconditionallyBridgeFromObjectiveC(_:)
MainThing.windowTitleChanged(_:axElement:notification:)
MainThing.focusedWindowChanged(_:window:)
MainThing.focusedAppChanged()

The process terminated with EXC_CRASH / SIGABRT on the main thread. This appears to mean that an Objective-C API returned an NSHTTPURLResponse where the Swift code expected a string, and the value was bridged without validating its runtime type.

Restart behavior

The Tauri manager logged:

[2026-09-14 17:33:55][INFO][aw_tauri_lib::manager] Stopped module: aw-watcher-window
[2026-09-14 17:33:55][INFO][aw_tauri_lib::manager] Module aw-watcher-window exited successfully

The native helper crashed, but the Python wrapper apparently exited with status 0. The manager therefore considered it a successful exit and did not restart the window watcher.

The silent exit/restart symptom resembles #101. The one-shot helper lifecycle and failure to restart are also discussed in #139, but the NSHTTPURLResponse exception appears to be a separate crash cause.

Expected behavior

1. Unexpected Accessibility or ScriptingBridge return types should be handled without crashing.
2. If the native helper crashes, the wrapper should return a failure status so the module manager can restart it.

Reproduction

No reliable reproduction yet. It occurred during an application/window focus change after several days of normal operation.

I have a macOS .ips crash report, but have not attached the raw file because it contains persistent device/session identifiers. I can provide a sanitized version if useful.

[ErikBjare]

@Gleek Thank you for reporting! Very helpful!

@TimeToBuildBob Please take a look at this and #139

[TimeToBuildBob]

Looked at both this crash and #139.

The abort is String._unconditionallyBridgeFromObjectiveC on kAXTitleAttribute. as? String still calls -[obj length], so a non-NSString (NSHTTPURLResponse here) kills the helper. Four days of uptime also matches the AXObserver Mach-port leak in #139; a leaked/stale AX value is a plausible source for that object.

#139's teardown bug is real: focusedAppChanged drops the run-loop source and then lets AXObserverCreate overwrite the previous observer without releasing it, and focusedWindowChanged unregisters the wrong notification (kAXFocusedWindowChangedNotification vs the kAXTitleChangedNotification it added). Gassandrid's patch on #139 is the right cleanup.

Third issue from this report: the Python wrapper ignored the helper's wait status, so SIGABRT still looked like a clean exit to aw-tauri (Module aw-watcher-window exited successfully) and window tracking stayed off.

Fix in #145:

• CF type-check AX strings/elements before bridging
• Unregister notifications, drop the run-loop source, and nil the observer before creating a new one
• Propagate helper signal deaths as a non-zero wrapper exit so the manager restarts it

I cannot compile the Swift helper from this Linux host; Python tests cover the exit-status path. A macOS smoke (make build-swift, port count under app switching) would still help before this lands in a beta.