Sandbox denies mach-lookup com.apple.cloudd only when app is launched outside Xcode (CKError 6)

Question

Created 4d

Replies 4

Boosts 0

Participants 2

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?

Answered by DTS Engineer in 901785022

I suspect you’re hitting the same problem as discussed in this thread.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Answer 1

DTS Engineer OP

Apple

3d

Recommended

I suspect you’re hitting the same problem as discussed in this thread.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Answer 2

bandithh07 OP

3d

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?

Answer 3

DTS Engineer OP

Apple

2d

Accepted Answer

Hmmm, you tried a lot of stuff but not the workaround from the recommended answer in the thread I referenced. Please add this line:

print(CKRecord.self)

to your app’s launch path (that is, some code that’s guaranteed to be run at launch) and then re-test.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Answer 4

bandithh07 OP

1d

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.