Every new VM on an external disk asks for removable-volume access, so clones always prompt #58

Description

Every new VM on an external disk triggers a macOS privacy prompt when it starts:

"" would like to access files on a removable volume. [Don't Allow] [Allow]

The prompt is tied to the VM, not to VMPal. Each VM runs as its own app (<VM>.vmpal/VM.app) with a bundle ID unique to that VM (com.tableplus.VMPal.vm.<id>), and macOS stores the Allow per bundle ID. So every clone gets a new identity and asks again, even when the VM it was cloned from was already allowed.

This breaks unattended agent workflows that clone a template VM for each task (vmpal_clone_vm + vmpal_start_vm over MCP, or vmpal clone --start from the CLI). The clone waits on the host dialog until someone clicks Allow.

The TCC log has no VMPal removable-volume prompts in the 5 days before 2026-10-15 20:21, then one per new VM. In that earlier period, the dock helper of new clones ran from another VM's bundle (/Volumes/ExternalDisk/Virtual Machines/Fedora VM.vmpal/VM.app/Contents/MacOS/VM), whose identity was already allowed, so no clone asked. Since then each VM runs its own VM.app and asks. Reinstalling older builds doesn't bring the old behavior back: new clones also prompt on 0.80, 0.81, 0.82 and 0.84.

Issue #53 (VMs on a non-OS drive won't start, no log) may have the same cause if that prompt was denied or never shown.

Steps to Reproduce

1. Keep a macOS VM in a location on an external disk (here /Volumes/ExternalDisk/Virtual Machines, a PCIe/Thunderbolt APFS SSD that macOS reports as Device Location: External).
2. Start it once and click Allow on the removable-volume prompt.
3. Clone it (VMPal's Clone, vmpal clone, or vmpal_clone_vm) and start the clone.
4. The prompt appears again, naming the clone. Click Allow, then clone and start again: it appears again.

Current Behavior

One TCC prompt per new VM. A sample from the host's TCC log, one per clone:

AUTHREQ_PROMPTING ... service=kTCCServiceSystemPolicyRemovableVolumes,
  subject=Sub:{com.tableplus.VMPal.vm.a9af195394144ae9b5e106070b8d4575}
  Resp:{TCCDProcess: identifier=com.tableplus.VMPal.vm.a9af195394144ae9b5e106070b8d4575,
  binary_path=/Volumes/ExternalDisk/Virtual Machines/<clone>.vmpal/VM.app/Contents/MacOS/VM}
AUTHREQ_PROMPTING ... service=kTCCServiceSystemPolicyRemovableVolumes,
  subject=Sub:{com.tableplus.VMPal.vm.ea4890f8c79e4cc9ab6492f6f1dd48f8}
  Resp:{TCCDProcess: identifier=com.tableplus.VMPal.vm.ea4890f8c79e4cc9ab6492f6f1dd48f8,
  binary_path=/Volumes/ExternalDisk/Virtual Machines/<clone>.vmpal/VM.app/Contents/MacOS/VM}

Without MDM there is no way to pre-approve this: PPPC profiles match exact bundle IDs only and can't be installed by hand, and tccutil can only reset.

Expected Behavior

Allowing VMPal's access to a VM location once covers every VM in it, including new clones. For example, the disk access could run under an identity macOS has already allowed (com.tableplus.VMPal / com.tableplus.VMPal.Machine, or VMPal as the responsible process), or clones could keep a stable identity for TCC.

Environment

• App version: VMPal 0.86 (Build 86); also reproduced on 0.80, 0.81, 0.82 and 0.84
• Mac: MacBook Pro, M4 Pro, 48 GB (Mac16,8)
• macOS version: macOS 27.0.1 (26A434)
• VM's OS: macOS 27.0.1 (26A434)

Log

The TCC lines above come from log show --predicate 'subsystem == "com.apple.TCC" AND eventMessage CONTAINS "RemovableVolumes"'. A diagnostics zip from vmpal_collect_diagnostics is available on request.