Summary
This postmortem analyzes a macOS Shortcuts Automation failure where external HDD folders appear greyed out and cannot be selected, even when Full Disk Access is enabled. The issue stems from how macOS Ventura/Sonoma/Tahoe handle sandboxed entitlement scopes, removable volumes, and automation security prompts.
Root Cause
The failure occurs because Shortcuts Automations run in a more restrictive sandbox than the interactive Shortcuts app. Even with Full Disk Access granted, the automation subsystem:
- Does not inherit the same entitlements as the Shortcuts editor
- Treats external/removable volumes as “untrusted” unless explicitly approved by system-level TCC (Transparency, Consent, and Control)
- Blocks folder selection when the automation’s entitlement profile does not match the required access level
- Fails silently, presenting the folder picker with greyed-out external volumes
In short: Full Disk Access ≠ Automation Disk Access.
Why This Happens in Real Systems
This is a classic example of privilege separation and sandbox mismatch:
- macOS uses multiple TCC layers, and automations run under a different process identity
- External drives are treated as higher‑risk because they can be removed, replaced, or spoofed
- Apple’s security model prioritizes preventing silent automation access to removable media
- The UI does not clearly communicate which subsystem is blocking access
This leads to a situation where the user believes they granted permission, but the automation runtime still refuses access.
Real-World Impact
Users experience:
- Greyed-out external drives in folder pickers
- Automations that cannot read or write to external disks
- Confusion because manual Shortcuts run fine, but Automations fail
- Inconsistent behavior between different macOS versions and hardware
- Workflows that break after OS updates due to tightened TCC rules
For engineers, this creates:
- Hard-to-debug permission failures
- Misleading UI states
- Support tickets that appear like user error but are actually OS-level sandbox constraints
Example or Code (if necessary and relevant)
Below is a minimal example of a shell script that would work if the automation had proper disk access, but fails when run via Shortcuts Automation due to sandbox restrictions:
#!/bin/bash
cp "/Volumes/ExternalHDD/data/input.txt" "$HOME/Documents/output.txt"How Senior Engineers Fix It
Experienced engineers approach this by working with macOS security boundaries rather than against them:
- Move the workflow to an internal drive and sync externally afterward
- Use Security & Privacy → Files and Folders to grant access to the specific app used inside the automation (e.g., Terminal, a script runner, or a helper app)
- Wrap the automation in a signed helper app with the correct entitlements
- Use Shortcuts → Ask for File actions to force a user‑approved file handle
- Store external-drive paths in Bookmarks (persistent security-scoped URLs)
- Avoid removable media in automations entirely when possible
The key insight: Automations must use security-scoped URLs, not raw file paths.
Why Juniors Miss It
Junior engineers often assume:
- “Full Disk Access” means full disk access
- The Shortcuts editor and Shortcuts automation runtime are the same process
- External drives behave like internal drives
- If a folder is greyed out, it’s a UI bug rather than a sandbox policy
They also tend to overlook:
- macOS’s layered TCC model
- The difference between interactive and automated execution contexts
- The need for security-scoped bookmarks for removable media
This leads to confusion and the belief that the system is malfunctioning, when in reality it is behaving exactly as designed.