macOS 26.6.1 on an M4 Mac mini, Xcode 26.6 (building against the macOS 26.5 SDK). Sandboxed SwiftUI app using NSPersistentCloudKitContainer. App: com.klausmack-software.NoteManagerPro Container: iCloud.com.klausmack-software.NoteManagerPro When I launch NoteManagerPro from Xcode, CloudKit sync works. When I launch the exact same build by double-clicking it — from /Applications or straight from the build products folder — CloudKit setup fails with CKError 6 ("Error connecting to CloudKit daemon"), and the kernel logs: Sandbox: NoteManagerPro(4338) deny(1) mach-lookup com.apple.cloudd launchd: denied lookup: name = com.apple.cloudd, requestor = NoteManagerPro[4338], error = 159: Sandbox restriction Sandbox: NoteManagerPro(4338) deny(1) mach-lookup com.apple.duetactivityscheduler Immediately before those lines: secinitd: NoteManagerPro[4338]: AppSandbox request successful kernel: (Sandbox) Sandbox apply: NoteManagerPro[4338] CloudKit additionally logs that the process may need (allow user-preference-read (preference-domain "com.apple.CloudKit")) in its sandbox profile. So the sandbox profile is built, but seemingly without the grants the iCloud entitlements should provide. Everything below is measured, not assumed: codesign -dv --verbose=4: signed with "Apple Development: Klaus Mack", valid on disk, satisfies its designated requirement, hardened runtime, flags=0x10000(runtime) codesign -d --entitlements: app-sandbox, network.client, files.user-selected.read-write, com.apple.developer.icloud-services (CloudKit), com.apple.developer.icloud-container-identifiers, com.apple.developer.ubiquity-kvstore-identifier, com.apple.developer.aps-environment (development), get-task-allow launchctl procinfo on the running process reports the same set as granted, plus "entitlements validated" Contents/embedded.provisionprofile present; platform OSX; contains this Mac's hardware UUID; entitlements include the iCloud container and both container environments Same failure for Debug and Release builds No effect from: deleting the app container (Terminal and Finder with authorisation), restarting the Mac, removing and re-adding the iCloud capability in Xcode, clearing Xcode's provisioning profiles A second app of mine on the same machine, same team, same development certificate, with an almost identical entitlement set, launches from /Applications and syncs without any problem — zero sandbox denials: App: com.klausmack-software.LicenseManager Container: iCloud.com.klausmack-software.LicenseManagerPro The only structural difference I can find is that in the working app the bundle identifier and the container name differ, while in the failing app the container is exactly iCloud. plus the bundle identifier. One more data point. If I change only the bundle identifier of the failing app to com.klausmack-software.NoteManagerPro2 and leave everything else alone, the sandbox denials disappear completely (zero), and CloudKit then reaches the server, which replies: CKError "Partial Failure" (2/1011); "Failed to modify some record zones" com.apple.coredata.cloudkit.zone:defaultOwner = CKError "Permission Failure" (10/2007); server message = "Invalid bundle ID for container" That error is expected, since the container is registered to the original identifier. Changing the identifier back reproduces the original CKError 6 and the sandbox denials exactly. That makes it look as though something is bound to the original bundle identifier rather than to the container directory, the signature, or the launch path. My questions: Where does the sandbox profile get its iCloud-related grants from, given that the entitlements are present and validated at process level? What persistent state could cause those grants to be omitted for one bundle identifier but not another on the same machine, with the same certificate and team? Is there a supported way to inspect or reset that state?

FileFerry is a native macOS file transfer client. It speaks FTP, FTPS (explicit AUTH TLS), SFTP, WebDAV and SMB, and opens a full SSH terminal on the same connection. Written in SwiftUI and AppKit, sandboxed, no third-party services. Requires macOS 14.6 or later. Free during the beta. https://testflight.apple.com/join/yY7JpHBP What I would most like tested The protocol side, against servers I have no access to: FTP directory listings from servers other than vsftpd and ProFTPD. MLSD is preferred where available; the LIST parser is the part most likely to break on an unusual date or month format, and a line it cannot parse means the file is missing from the table. FTPS against servers that require TLS session reuse on the data connection. vsftpd defaults to requiring it; the app uses separate connections and reports 522 with an explanation rather than failing silently. Self-signed certificates and host key changes. Fingerprints are confirmed once and then checked every session; a changed one refuses the connection, with no override. SMB shares with unusual permissions or on non-standard ports. Also worth breaking Transfers are retried three times, then verified — SHA-256 over SSH for SFTP in both directions, file size for FTP uploads. Anything that still fails goes on a list that survives quitting the app, so a connection lost part way through a large directory can be picked up afterwards. Nothing on the server is ever deleted automatically. Feedback through TestFlight reaches me directly. Bug reports with the session log are the most useful — the app shows the full wire dialogue and can write it to a file.