Same failure here, Team 4G35KLFD64, macOS app Kaleidoscope, Xcode Cloud builds 11017, 11020 and 11021 (Nov 3–4). App Store and Development exports in the same builds succeed; only the Developer ID export fails. From the export logs: The certificate query for DEVELOPER_ID_APPLICATION_MANAGED returns "total" : 0. The create request returns HTTP 409, ENTITY_ERROR, resultCode 7460: "You already have a current Developer ID Application Managed certificate or a pending certificate request." The export then fails with No "Developer ID Application" signing certificate matching team ID "4G35KLFD64" with a private key was found. A few data points that might help narrow this down: Timing. Build 11016 on Oct 15 still signed with the managed certificate (ID PXZ54PQ6QZ, serial 02D86889999D3EA2). That certificate was issued Aug 18, 2026 by the previous Developer ID Sub-CA and expires Feb 1, 2027. Nov 3, the first failing build, is exactly 90 days before that expiry, which is when the automatic rotation is documented to start. The certificates in the other reports here expire Feb 1–2, 2027 as well, so this looks like the automatic rotation to the G2 Sub-CA stalling, not a per-team misconfiguration. Portal vs. API. The managed certificate is still listed in Certificates, Identifiers & Profiles for our Account Holder, while the Xcode Cloud certificate API returns an empty list for the type. Admins on the team do not see it in their list at all. Manual rotation does not help. Our Account Holder clicked Rotate on the certificate; the dialog states manual rotation is available from six months after creation until 90 days before expiry, which this certificate is outside of. The next build failed identically. Revoking is not an option for us. The managed certificate has signed every build we shipped since August. Per the Developer ID support page, apps signed with a revoked Developer ID certificate can no longer launch. We would appreciate confirmation from DTS whether that applies to cloud-managed certificates as well, since the accepted answer in thread 853905 recommends revoking. Error ID from build 11020, in case it helps whoever looks at the server side: 0ae275a5-d31e-4822-b2ac-8763c13e2162. A Developer Support case is being opened by our Account Holder.

We did this transfer in March: iOS app and native Mac app, different bundle IDs, same intents, both moved to a new team. App Intents, not an Intents extension. A shortcut stores per action an AppIntentDescriptor with BundleIdentifier, AppIntentIdentifier, Name and TeamIdentifier. Shortcuts created before the transfer still carry the old TeamIdentifier. To see it: share the shortcut as an iCloud link and download the shortcut field from https://www.icloud.com/shortcuts/api/records/. Same platform: shortcuts from before the transfer kept working. Resolution goes by the bundle identifier, which does not change. Cross-platform: Shortcuts maps an action to the app on the other platform by intent name, but only within the same team (WWDC21 “Meet Shortcuts for macOS”). Shortcuts from before the transfer fail on the other platform with a missing action; the user has to rebuild them. Testing without a transfer is not possible, since one explicit App ID cannot be signed by two teams.

Here is mine: FB23072413

The same thing also happens on M1 and M2 Macs, but you would not notice, because the device is not getting hot and the fans are not spinning loudly. I just wanted to mention it, because there are rumors on the web that it only affects Intel based Macs. Entering sudo pmset schedule cancelall in Terminal works on M1 Macs too...