pac code push returns HTTP 500 for any service-principal identity (secret or certificate), while interactive user auth always succeeds

[kippolitov]

Title

pac code push returns HTTP 500 InternalServerError for any application/service-principal identity (client secret or certificate), while identical push succeeds under interactive user auth

Summary

pac code push consistently fails with a generic 500 InternalServerError when the active pac auth profile is an application/service-principal identity, even though:

• The same service principal successfully authenticates and performs other operations in the same environment (solution import/export, publish) via the official microsoft/powerplatform-actions GitHub Actions.
• The service principal is fully registered: it has a Dataverse Application User with the System Administrator role, and it appears in the tenant's adminApplications list (GET https://api.bap.microsoft.com/providers/Microsoft.BusinessAppPlatform/adminApplications), confirming BAP-level registration (the same registration pac admin create-service-principal performs).
• Pushing the identical build (power.config.json + dist/) to the identical appId/environment via interactive user auth (pac auth create with a browser sign-in) always succeeds.
• The failure reproduces identically across two independent Dataverse environments (dev and production), across ubuntu-latest and windows-latest GitHub Actions runners, and across three separately-minted Code App appIds.
• Credential type does not matter: we additionally tested certificate-based service principal auth (pac auth create --certificateDiskPath ... --certificatePassword ...) as an alternative to the client-secret flow. Authentication cleanly succeeds (Successfully acquired a token using profile of type AppCertificate for scope 'https://api.powerplatform.com/.default'), and the push still fails with the identical 500 on the identical endpoint. This rules out anything specific to client-secret credentials -- the failure is tied to the token being an application/service-principal token at all, regardless of how that identity authenticates.
• We confirmed via the app's own "Modified" timestamp (make.powerapps.com app details pane) that this is not a false-negative: an app's Modified timestamp never advances past its original creation moment despite dozens of subsequent pac code push attempts via the service principal (all reporting this same 500), while a one-off interactively-authenticated push updates it immediately. The service principal has never successfully updated Code App content in our project's history -- not once, across ~2 days and dozens of attempts.

Environment

• pac CLI version: 2.8.1+ga4eb71c (.NET 10.0.9)
• Reproduced on: GitHub Actions ubuntu-latest (Ubuntu 24.04) and windows-latest (Windows Server 2025 Datacenter)
• Auth: service principal / client credentials flow (pac auth create --applicationId ... --clientSecret ... --tenant ...)

Steps to reproduce

1. Register a service principal as a Dataverse Application User (System Administrator role) in a Power Platform environment with Code Apps enabled.
2. pac auth create --applicationId <appId> --clientSecret <secret> --tenant <tenantId> --environment <envUrl> --accept-cleartext-caching (or --certificateDiskPath/--certificatePassword instead of --clientSecret -- same result)
3. pac code init (or use an existing power.config.json) and build the app.
4. pac code push

Expected

The Code App publishes successfully, as it does under interactive user auth for the identical appId/environment/build.

Actual

Successfully acquired a token using profile of type Application for scope 'https://api.powerplatform.com/.default'
HTTP error status: 500 for PUT https://<env>.environment.api.powerplatform.com/powerapps/apps/<appId>?api-version=1: {"error":{"code":"InternalServerError","message":"Encountered internal server error. The correlation Id is '<guid>'."}}

Sample correlation IDs from repeated reproductions (available for backend log lookup if useful):

• 9be8e65d-7325-4eae-be06-e0b6d470c578
• 2656be21-0d5e-4da5-b721-402011248238

Additional context

• This is separate from, and downstream of, an unrelated auth-transport bug we also hit and worked around (pac auth create's persisted profile not retaining a usable client secret for later token refresh — see pac command work initially but starts failing with auth issues after ~ 1 hours powerplatform-vscode#297 and #456, worked around via the PAC_CLI_SPN_SECRET env var documented there). Once that workaround was applied, the SP reliably acquires a valid token for the https://api.powerplatform.com/.default scope — the 500 above happens after successful authentication, on the actual PUT call.
• Service principal limitations documentation lists supported SP scenarios as "environment management, tenant settings, and Power Apps management" — Code Apps isn't explicitly listed, so this may be a known gap rather than a regression. Filing in case it's actionable or already tracked internally.

Impact

Blocks fully non-interactive CI/CD deployment of Code Apps (e.g. via GitHub Actions with microsoft/powerplatform-actions) using service principal auth, which is the standard, documented, MFA-compatible auth pattern for CI/CD against Power Platform.