macOS clipboard stays stale after vdagent crash because KeepAlive.Crashed is false

[elpinguinofrio]

Summary

On a macOS guest, clipboard sharing became permanently stuck on stale content after the per-user spice-vdagent process crashed once. The agent did not restart automatically. Manually kickstarting the LaunchAgent immediately restored host-to-guest clipboard updates.

Both macOS plists currently set:

<key>KeepAlive</key>
<dict>
    <key>Crashed</key>
    <false/>
</dict>

According to launchd.plist(5), Crashed=true restarts a job after a crash signal such as SIGSEGV; false restarts it only in the inverse condition. Consequently, a single crash leaves the clipboard agent stopped indefinitely.

Environment

• macOS guest: 15.7.3 (24G419), arm64
• Virtual machine: Apple Virtualization backend (Apple Virtual Machine 1)
• Guest tools package: com.redhat.spice.vdagent 0.22.1
• Installed plist matches the current repository version

The host UTM version was not available from inside the guest, but the issue is in the guest LaunchAgent policy and the installed package matches this repository's latest release.

Observed evidence

After clipboard synchronization stopped:

$ launchctl print gui/501/com.redhat.spice.vdagent
state = not running
runs = 1
successive crashes = 1
last terminating signal = Segmentation fault: 11

At the same time:

• spice-vdagentd was running.
• /dev/tty.com.redhat.spice.0 existed.
• /var/run/spice-vdagent-sock existed.
• The local macOS pasteboard service was running.

Restarting the user agent:

launchctl kickstart -k gui/$(id -u)/com.redhat.spice.vdagent

produced:

state = running
runs = 2

While copying fresh text on the host, the guest NSPasteboard.changeCount then changed from 358 to 359, and the new host text pasted successfully in the guest. This rules out the host clipboard setting, virtio channel, and guest pasteboard as the persistent failure.

The original agent crash trigger was not recovered because no .ips crash report was generated. This issue is specifically about the deterministic failure to recover after any crash.

Likely regression

Commit c729770 ("darwin: fix launch scripts") changed Crashed from true to false in both:

• com.redhat.spice.vdagent.plist
• com.redhat.spice.vdagentd.plist

That appears to invert the intended restart behavior. The daemon is exposed to the same permanent-stop failure if it crashes.

Expected behavior

If spice-vdagent or spice-vdagentd crashes, launchd should restart it (with appropriate throttling) so clipboard sharing recovers without requiring a VM reboot or manual launchctl kickstart.

Suggested fix

Restore <true/> for KeepAlive.Crashed in both macOS plists, or add another supervised recovery mechanism if avoiding an unbounded crash loop is the reason for the current setting.

[elpinguinofrio]

Confirmed recurrence on 2026-07-21 after a fresh guest reboot at 09:04 WITA.

Before any repair on this boot:

gui/501/com.redhat.spice.vdagent:
state = not running
runs = 1
successive crashes = 1
last terminating signal = Segmentation fault: 11

system/com.redhat.spice.vdagentd:
state = running
pid = 266

So this was the same failure mode again: the session agent crashed once during/after login and remained dead, while the daemon was healthy. Clipboard synchronization was stale until the agent was kickstarted.

I installed a user-local watchdog as an interim mitigation. It runs every 10 seconds, checks the existing gui/$UID/com.redhat.spice.vdagent launchd job, and calls launchctl kickstart only when that job is stopped.

I then verified automatic recovery by deliberately reproducing the exact crash signal:

Before test: runs = 2, pid = 24930
Action:      launchctl kill SIGSEGV gui/501/com.redhat.spice.vdagent
Watchdog:    2026-07-21T09:44:58+0800 restarted gui/501/com.redhat.spice.vdagent
After test:  runs = 3, successive crashes = 2, pid = 27447, state = running

After another 12 seconds, the agent was still on run 3 / PID 27447, confirming that the watchdog leaves a healthy process alone. The watchdog error log was empty, and spice-vdagentd logged the virtio channel reopening at the same timestamp.

This makes the impact concrete across multiple boots: every macOS guest using the current plist can remain without clipboard synchronization after a single agent crash. The user-local watchdog works, but changing KeepAlive.Crashed back to true in the packaged LaunchAgent remains the correct upstream fix.