Investigate rapid self-lock loop on asiago observed during lock-guard's first live run

[twistedmelonman]

Observation

On 2026-08-12, while first testing lock-guard live on asiago (the Synergy controller, which is also in its own client list — every fan-out cycle locks itself via SSH-to-self), the controller entered a rapid repeating lock loop: 8 locked events between 20:14:25Z and 20:15:06Z, roughly 5-7 seconds apart — too mechanically regular to be manual unlock/relock by the operator, who confirmed they weren't repeatedly interacting with the machine during that window.

2026-08-12T20:14:25Z locked
2026-08-12T20:14:28Z client=asiago.local user=andrewrich ssh_exit=0
...
2026-08-12T20:14:30Z locked
2026-08-12T20:14:34Z client=asiago.local user=andrewrich ssh_exit=0
...
(repeats 8 times total, ending 20:15:06Z)

In every iteration, asiago.local (locking itself, since it's in its own Synergy client list) succeeds with ssh_exit=0 a few seconds before the next locked event fires — consistent with asiago's own lock-guard/pmset invocation somehow re-triggering com.apple.sessionagent.screenIsLocked, which lock-watcher subscribes to.

This timing coincides with lock-guard going live on asiago for the very first time (via a freshly-run bin/install), meaning check_meet_tab_open()'s osascript call to Chrome was running live for the first time in that window, potentially triggering a first-run macOS Automation permission dialog while the screen was locked.

Investigation performed (2026-08-12, same day)

• Reproduced two clean single-lock cycles after the burst (21:02:08Z and 21:06:56Z): each produced exactly one locked event with no repeat.
• Manually ran the exact osascript command check_meet_tab_open() uses, live, while the screen was locked. Result: instant failure —
  execution error: Not authorized to send Apple events to Google Chrome. (-1743) — no hang, no display wake observed, no loop triggered.
• This rules out "osascript live-driving Chrome causes a display wake" as the current mechanism, since the call now fails immediately on the authorization check before ever reaching Chrome.

Open question

The loop has not reproduced since the initial burst and the current osascript call fails fast (unauthorized) rather than hanging or waking the display. The working theory is that the burst was a one-time artifact of lock-guard's very first live run on asiago — possibly a first-run Automation permission dialog appearing on the (locked) screen and interacting with the lock/wake state in some way — but this is unconfirmed. No root cause has been definitively established.

Follow-up if it recurs

• Check Console.app / log show for wake/sleep and Automation-permission-prompt events correlated to the timestamp of any future recurrence.
• Consider whether check_meet_tab_open() should skip entirely (return "no match" immediately) if the Automation permission is not granted, rather than attempting the osascript call at all — this wouldn't explain the burst (since the call currently fails fast either way) but would reduce the window for any macOS-side side effects of the attempt itself in future first-run scenarios (e.g. a permission-prompt dialog).
• Consider whether asiago (or any controller that is also a member of its own Synergy client list) should be excluded from its own fan-out, since SSH-to-self achieves nothing a local pmset displaysleepnow/lock-guard invocation wouldn't, and removes any risk of a self-referential trigger entirely — this is a design question, not clearly a bug fix, and is separate from root-causing the specific burst above.

[twistedmelonman]

Scope narrowed to self-exclusion only, per repo owner decision. This issue's other suggested follow-up — having check_meet_tab_open() skip entirely when the Automation permission hasn't been granted — is deliberately not implemented here, since it wouldn't explain the original burst either (the osascript call already fails fast on the authorization check) and the burst hasn't recurred since. Left as a possible future issue if it does recur.

Self-exclusion is implemented in #32: lock-fanout now skips any host that resolves to the controller itself (case-insensitive match against hostname -s + .local), logging client=<host> warn=skip-self instead of SSHing to itself.