The Probe Has to Run Where Dad Does
A probe that starts sessions on other Macs has to start them somehow, and the obvious way is ssh. On 2026-11-10 that obvious way produced a misleading answer: Claude Code and Cursor's agent both came back unavailable over ssh, "not signed in", on Macs where Dad used them every day.
The cause is macOS's login keychain. Some harnesses keep their sign-in token there. In Dad's own login session the keychain is unlocked and a token refresh just works. In an ssh session, the login keychain is locked, so the refresh fails, and the harness reports that it is not signed in. That failure happens only over ssh and nowhere real. A probe that trusted it would report a surface as broken that was fine, or, worse, would teach everyone to shrug at "unavailable".
Two Ways to Start a Session
The fix runs each harness where its sign-in actually works:
- Keychain harnesses (
GUI_SESSION_HARNESSES: Claude Code and Cursor's agent) run as a transient launchd job in that account's GUI login session, the same place Dad's own sessions run. Run that way, both were Pippa. - Every other harness signs in from files and runs over ssh as before. The reason they do not go to the GUI session too is the mirror image: in a GUI session nobody watches, a sign-in refresh can stop on a dialog and wait until the probe's deadline.
- An account with no GUI session at all runs its turn over ssh.
Every result records which way it ran: local, gui or ssh. A reader of the receipt can see not only what answered but under what conditions.
What the Probe Cannot Reach, It Lists
Some surfaces have no headless entry at all, and the probe does not pretend otherwise. A table in the source, NOT_COVERED, names each with its reason, and every receipt prints it: the native Firebrand app (covered only through the Firebrand CLI's identity path), IDE chat panes such as Cursor's IDE, Trae and Antigravity, Pippa's Telegram route (a live probe would message Dad's phone), the voice route (checked through the WebUI's prompt), Pippa's own home Mac (outside fleet operations by Dad's ruling), Mom's Mac and the Windows readers (each needing separate fresh-session evidence). A gap that is listed is a decision. A gap that is silent is a bug.
Zero Evidence Is Not a Pass
One more episode from the independent review is the purest form of this lesson. A 65-entry identity matrix was run from a lab account, and every entry came back with an ssh host-key verification error: no session started, no answer was given. The review's verdict was precise: "That is zero identity evidence, not 65 vendor-voice answers and not a pass." The fix was not to copy login material or weaken trust settings to make the matrix run; it was to leave the final harness evidence to the separately assigned identity work (Coop 1110-44), which later reviewed 68 fresh sessions across 38 host-and-account combinations by hand, and stated its own limits as plainly as its passes.
Reading a Matrix Honestly
Probe matrices in this project are full of unavailable. At the cutover: eight Macs, 69 rows, 15 pass, 46 could not start, and the remaining eight read by hand (Track 7, lesson 3: a retried pass, the baseline's known red and a new Mac's refusal among them). Around contract v7: 65 rows, 20 pass, 45 unavailable, before and after. Those numbers are not embarrassing. They are a census of which harnesses exist and are signed in on which Macs. The numbers that matter are the comparisons: no fail that was not a fail before, and no surface that passed before is suddenly unavailable. The comparison catches that second move only from a pass; a baseline fail that turns unavailable goes quiet, so those rows are read by hand.