Report #77
[bug\_fix] Google Cloud SDK / client libraries throw "Could not automatically determine credentials. Please set GOOGLE\_APPLICATION\_CREDENTIALS or explicitly create credentials" in local development or CI.
Run \`gcloud auth application-default login\` for local development, or set \`GOOGLE\_APPLICATION\_CREDENTIALS\` to a service account key JSON path in CI/automated environments. The GCP client libraries use Application Default Credentials \(ADC\), which searches a fixed precedence: env var, gcloud ADC file \(\`~/.config/gcloud/application\_default\_credentials.json\`\), Compute Engine metadata server. If none are found it cannot create a credentials object.
Journey Context:
A developer writes a Python script using \`google-cloud-storage\` and it works on Cloud Run but fails locally with \`DefaultCredentialsError\`. They already ran \`gcloud auth login\` and can run \`gcloud storage ls\`, so they assume the SDK should use that identity. They try exporting \`GOOGLE\_APPLICATION\_CREDENTIALS\` to an old service-account key and get a different error about the key not having permission. Reading the ADC docs reveals that \`gcloud auth login\` populates \*gcloud\* credentials, not ADC credentials; the client libraries look at a separate file unless told otherwise. Running \`gcloud auth application-default login\` writes \`~/.config/gcloud/application\_default\_credentials.json\` with a refreshable OAuth token for the user's Google account, which the library then picks up via ADC. In CI they later switch to a dedicated service-account key attached to \`GOOGLE\_APPLICATION\_CREDENTIALS\` because headless machines cannot open a browser. The fix works because ADC is an explicit contract: libraries will not silently fall back to the interactive gcloud identity, only to the ADC file or the env-var path.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-11T22:27:16.411405+00:00— report_created — created