The -1712 "AppleEvent timed out" on m3ultra was not the screen lock (2236a96 is wrong).
The user TCC db says it plainly:
m3ultra: /bin/sh -> com.google.Chrome auth_value=0 DENIED
(no row at all for /bin/sh -> com.brave.Browser)
ultra: /bin/sh -> com.brave.Browser auth_value=2 allowed
The launchd job IS `/bin/sh -c exec launch.sh`, so that one row kills it, and a DENIED
Automation grant surfaces as a ~2-minute hang then -1712, never a clean -1743. The
`sshd-keygen-wrapper -> {finder,systemevents,Brave,Chrome} = 0` rows are why AppleEvents
also failed from ssh on BOTH Macs — which is what made the lock look causal.
Two corrections to my own reasoning:
* `name`/`version`/`running` of an application are answered from the app bundle WITHOUT
sending an AppleEvent, so "app-level AE works, window-level hangs" was never evidence.
* the lock guard could wrongly stop a working rig (a locked screen was never shown to
break a granted AppleEvent). Removed the gate.
launch.sh now attempts the AppleScript and, only on failure, reads the TCC row for
(/bin/sh -> this browser's bundle id) and prints which of the three states it is:
denied / allowed-but-unresponsive / never-prompted.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
1. LOCKED SCREEN. With CGSSessionScreenIsLocked=Yes, every AppleScript window/tab query
hangs ~2 min and returns -1712 "AppleEvent timed out". This is NOT a browser bug —
with m3ultra locked, `count of windows` hung identically for Chrome, Brave, Finder
AND System Events, while app-level properties (name/version/running) answered instantly.
launch.sh now checks the lock first and exits 0 with an instruction, so the 10-min tick
retries instead of leaving two osascript processes wedged.
2. `open location "$URL"` is Standard Additions: it hands the URL to the DEFAULT browser,
never to $BROWSER. m3ultra's default is Brave while the extension lives in Chrome, so
the fresh-open path would have opened the wrong browser entirely. Now makes the tab
inside the target app.
3. Wrapped the tell block in `with timeout of 30 seconds` so a wedged app can't hold the job.
Verified: detector reports unlocked on ultra / LOCKED on m3ultra; after the fix m3ultra
logs the instruction and exits with no hung osascript, ultra still logs "focused on Flow".
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Three bugs, all found standing up a second rig on m3ultra:
1. SECURITY: HTTPServer(("", 8017)) bound 0.0.0.0 with no auth, and POST /save
base64-writes bytes to an absolute `dest` taken straight from the request body.
Anyone on the same wifi could write arbitrary files as this user — drop a
~/Library/LaunchAgents plist and you have code execution. It was live on ultra
(verified: `TCP *:8017 (LISTEN)`, 204 from 192.168.1.249). Now binds 127.0.0.1;
FLOW_BIND overrides for a tailnet IP (utun-routed, LAN still can't reach it).
2. The launchd "self-heal" never healed anything. launch.sh backgrounds the queue
server and exits; without AbandonProcessGroup launchd SIGKILLs the process group
on exit, so every 10-min tick started a server that died a second later. The
server that was actually up had been started by a manual ./launch.sh.
Verified after the fix: kill -> 000 -> kickstart -> 204 on a fresh pid.
3. launch.sh hard-coded "Brave Browser" in the osascript. The extension is loaded
into Chrome on m3ultra. FLOW_BROWSER now names it (default Brave, unchanged
for ultra); m3ultra's plist sets "Google Chrome".
Also chmod +x install.sh launch.sh (both had lost the bit).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
