Pasted/AirDropped file attachments land in unreadable sandbox path on macOS

Summary

When a file is shared into the prompt via the macOS shared-pasteboard route (paste from AirDrop, drag-in from another app), the harness substitutes a path under ~/Library/Group Containers/group.com.apple.coreservices.useractivityd/shared-pasteboard/items/<uuid>/<name>. That path is not readable from Claude Code's sandbox — both Read and Bash cp/cat fail with EPERM: operation not permitted.

Repro

1. AirDrop a file from another device to the Mac (or copy a file in Finder so it lands in the shared pasteboard).
2. Paste / drop it into the Claude Code prompt — the input renders as a path like:

``
/Users/<me>/Library/Group Containers/group.com.apple.coreservices.useractivityd/shared-pasteboard/items/B191DE22-AB04-4E17-89EF-146B2361CEBE/A-2.gpx
``

1. Ask Claude to read it.

Observed:

Read → EPERM: operation not permitted, open '…/A-2.gpx'
cp   → cp: …/A-2.gpx: Operation not permitted

Expected

Either:

• Copy attachments into a sandbox-readable location (e.g. session tmp dir) before substituting the path into the prompt, or
• Extend read permission to the exact attachment path for the duration of the turn.

Impact

Any file shared via the macOS shared-pasteboard / AirDrop pipeline is silently unreadable. The user has to cp the file out manually before Claude can see it, which defeats the point of pasting an attachment.

Environment

• Platform: macOS, Darwin 25.2.0
• Claude Code CLI (Opus 4.7, 1M context)