I’m investigating an authentication discrepancy in CloudKit’s Development private database, using a Safari Dock web app on macOS 26.5. All records contain fabricated test data. Names below are anonymized. In one signed-in SDK session, records/lookup successfully read a private default-zone marker. The following zones/lookup for TestZone failed with auth-failed/noAccount. Two private reads, zero writes. A separately inspected full-trial zone request returned AUTHENTICATION_FAILED with the reason: “Authentication failed. Please check you have the correct API token for this container.” In a fresh session, records/lookup directly read metadata for TestHead in TestZone and returned revision 1. It used zoneID and non-asset desiredKeys, without zones/lookup. One private read, zero asset downloads, zero writes. The existing website API token was recopied from the selected container, not regenerated. The inspected request Origin matched the configured allowed origin. The app uses a custom fetch adapter and RAM-only authTokenStore. It checks identity before private requests and rebinds only ckWebAuthToken to the token validated by that check. This is not an unmodified SDK request path. Does private zones/lookup have a documented authentication requirement that differs from records/lookup? Could this custom request handling explain these results? The root cause is still unconfirmed.

I’m investigating an authentication discrepancy in CloudKit’s Development private database, using a Safari Dock web app on macOS 26.5. All records contain fabricated test data. Names below are anonymized. In one signed-in SDK session, records/lookup successfully read a private default-zone marker. The following zones/lookup for TestZone failed with auth-failed/noAccount. Two private reads, zero writes. A separately inspected full-trial zone request returned AUTHENTICATION_FAILED with the reason: “Authentication failed. Please check you have the correct API token for this container.” In a fresh session, records/lookup directly read metadata for TestHead in TestZone and returned revision 1. It used zoneID and non-asset desiredKeys, without zones/lookup. One private read, zero asset downloads, zero writes. The existing website API token was recopied from the selected container, not regenerated. The inspected request Origin matched the configured allowed origin. The app uses a custom fetch adapter and RAM-only authTokenStore. It checks identity before private requests and rebinds only ckWebAuthToken to the token validated by that check. This is not an unmodified SDK request path. Does private zones/lookup have a documented authentication requirement that differs from records/lookup? Could this custom request handling explain these results? The root cause is still unconfirmed.