VM→host clipboard silently drops the 2nd VM when running multiple VMs simultaneously (shared dedup in singleton WHSharedClipboardService)

[marcel-veselka]

Summary

When two macOS VMs run at the same time (both with VirtualBuddyGuest installed), VM→host clipboard works for only one of them. host→VM works for both. The VM started first keeps working; the second VM's clipboard is silently dropped — the guest reads/exports it fine, but the host never applies it to NSPasteboard.general.

Environment

• VirtualBuddy 2.1 (build 325), VirtualBuddyGuest 2.1 (325)
• Host and both guests: macOS 26.5.1 (25F80), Apple Silicon
• Two macOS VMs running concurrently

Repro

1. Create two macOS VMs, install VirtualBuddyGuest in both.
2. Start VM A, then VM B.
3. Copy text in VM B → paste on host: nothing (host keeps its old clipboard).
4. Copy text in VM A → paste on host: works.
5. host→VM works for both. Frontmost/focused VM makes no difference; restarting the guest doesn't help.

Root cause (from source, current HEAD)

The host clipboard receiver is a process-wide singleton with a single shared dedup field, fed by all VMs at once:

• WormholeManager.sharedHost is a singleton; its services are built once on first activate() (WormholeManager.swift:36-37, 77-93), so there is exactly one WHSharedClipboardService for every VM.
• It subscribes to the merged stream of all peers and discards the sender ID:

// WHSharedClipboardService.swift:40-47
for try await message in connection.stream(for: ClipboardMessage.self) {
    handle(message.payload)   // message.senderID is dropped
}

• handle() dedups against a single shared previousMessage:

// WHSharedClipboardService.swift:51-58
private func handle(_ message: ClipboardMessage) {
    guard !message.data.isEmpty, message.data != previousMessage?.data else { return }
    previousMessage = message
    pasteboard.read(from: message.data)
}

That same previousMessage is also written by the host→VM poll (updateIfNeeded, :73-89) and by guest↔guest propagation (propagateBetweenGuests = true). With two VMs, whichever VM owns the shared baseline (the first-started one in steady state) keeps working; the other VM's distinct copies are classified as duplicates at :52 and dropped — "guest exports fine, host never applies it."

Transport is not the problem: each VM gets its own serial pipe pair and a distinct peer ID (VMInstance.swift:167-191), so there's no port/service-name collision. The issue is the shared previousMessage + single NSPasteboard in the singleton service.

Suggested fix

Make the dedup per-peer and stop dropping the second VM:

• Keep message.senderID (already available at :42) and pass it into handle().
• Replace the single previousMessage with a [WHPeerID: ClipboardMessage] keyed by sender, and track the host's last-applied content separately so an inbound copy that merely equals what the host just broadcast to that peer isn't mistaken for a duplicate from another peer.
• Optionally track NSPasteboard.general.changeCount for host-side change detection instead of value-comparing on a 0.5s timer.

Happy to test a patch. Thanks for VirtualBuddy — it's excellent.