That fixed it. Thank you — and thank you for pushing me back to the recommended answer in the referenced thread. I had read the thread but missed that workaround entirely. For anyone finding this later, here is what my case looked like: My app uses CloudKit only indirectly, through NSPersistentCloudKitContainer. It never references a single CloudKit symbol of its own. So the framework was not loaded at launch, the sandbox came up without the iCloud exception, and the kernel denied com.apple.cloudd and com.apple.duetactivityscheduler — resulting in CKError 6 on every launch that did not come from Xcode. Launched by Xcode it always worked, which is what kept me looking in the wrong place. Adding a line that touches CloudKit at the very start of the launch path was enough. Everything else I had compared between a working app of mine and this one — entitlements and their values, embedded profiles and the entitlements they grant, provisioned devices, signing identity, Designated Requirement, quarantine, build configuration, copy method and launch location — was identical, so I never would have found this by comparing state. The difference was not what the apps are but what they do at launch. Much appreciated.

Thanks for the pointer. That thread shows the same two sandbox denials, but the case there is a Store profile. Mine is a development profile, so I ran a controlled comparison of two of my own apps on one machine. The result is a contradiction I cannot explain, and I would appreciate guidance. Setup macOS 26.6.1, Xcode 26.6. Sandboxed macOS app, Core Data with NSPersistentCloudKitContainer, automatic signing, Apple Development certificate, Xcode-managed "Mac Team Provisioning Profile". Symptom CloudKit fails with CKErrorDomain Code=6 whenever the app is launched by anything other than Xcode. The kernel logs: Sandbox: NoteManagerPro(44046) deny(1) mach-lookup com.apple.duetactivityscheduler Sandbox: NoteManagerPro(44046) deny(1) mach-lookup com.apple.cloudd Launched by Xcode, the same bundle works perfectly: the profile is evaluated, TCC approves the container, and there is real traffic to gateway.icloud.com with no errors. The control case A second app of mine on the same Mac, same team, same Apple Development certificate, its own Xcode-managed Mac Team Provisioning Profile, also sandboxed and also using CloudKit. It works when launched from /Applications. The only difference in the log is whether the embedded profile is evaluated at all. Working app, launched from /Applications: amfid: Entering OSX path for /Applications/LicenseManagerPro.app/Contents/MacOS/LicenseManagerPro taskgated-helper: Checking profile: Mac Team Provisioning Profile: com.klausmack-software.LicenseManager taskgated-helper: allowing entitlement(s) for com.klausmack-software.LicenseManager due to provisioning profile (isUPP: 0) Failing app, launched from /Applications: no amfid line, no taskgated-helper line at all. The sandbox denials follow immediately. Ruled out, all measured Entitlements claimed by the binaries are identical in keys and values, except that the working app additionally claims com.apple.security.personal-information.photos-library. Both embedded profiles grant identical entitlement sets, including icloud-services, icloud-container-identifiers, icloud-container-environment (Production, Development) and aps-environment. Both profiles are valid until 2027 and both list this machine's provisioning UDID. Same signing authority (Apple Development, same team identifier), hardened runtime in both. No quarantine attribute on either bundle. Release build, single executable, no debug dylib. Deleting the app from /Applications, emptying the trash and copying it in again: unchanged. Copying with ditto instead of Finder: unchanged. Launching from ~/Documents: unchanged. Launching by double-click from inside the Xcode build folder: unchanged. So it is not the location and not the copy operation, only whether Xcode is the launching process. /var/db/MobileDevice/ProvisioningProfiles does not exist on this machine, so neither app has a system-installed profile. Question What determines whether taskgated-helper evaluates the embedded provisioning profile at launch? Two apps with equivalent signatures, equivalent embedded profiles and the same provisioned device behave differently on the same machine, and only one of them gets its entitlements allowed. And is there a supported way to have an embedded development profile honoured for a normal Finder launch, or is a Developer ID signature with notarisation the only path for testing a CloudKit app outside Xcode?