Reference creatortrack google oauth project

URL: https://mkdocs.justinsforge.com/memory/general/reference_creatortrack_google_oauth_project/

CreatorTrack's Google OAuth (calendar/gmail connect flows on app.creatortrack.ai) uses GCP project creatortrack-499820 (project number 1090092084768), client id 1090092084768-5gsla4a129rv7g52vb69379lakbje7ic. Secret: ~/.forge-secrets/creatortrack-auth.env (AUTH_GOOGLE_ID / GOOGLE_CLIENT_ID).

Gotchas hit 2026-07-07 connecting Google Calendar: 1. 403 access_denied = consent screen in Testing mode blocks non-test-users on sensitive calendar scope. Fix: add test user OR publish to Production. Publishing is preferred because Testing-mode refresh tokens expire after 7 days (sync dies weekly); Production tokens persist. Unverified Production just shows a one-time "Advanced -> proceed" warning per account; 100-user cap until verified. Console: https://console.cloud.google.com/auth/audience?project=creatortrack-499820 2. 403 "Calendar API has not been used in project" = API disabled. Fixed by gcloud services enable calendar-json.googleapis.com --project=creatortrack-499820. Takes 1-2 min to propagate.

2026-07-10: YouTube Data + Analytics APIs enabled (youtube.googleapis.com, youtubeanalytics.googleapis.com). Members (Michael) can now use Content Research via their own Google connection: youtubeToken() in lib/research/research.ts falls back to the caller's provider-"google" connection with the youtube scope group (minted via accessTokenForConnection) before the owner-only forge token; the no-auth card has a "Connect YouTube" button hitting /api/google/connect?groups=youtube. Deployed commit af8f1f3. No UI path requests Gmail (restricted) scopes, so unverified-Production only shows the bypassable "Advanced -> proceed" warning. Consent-screen publishing status has NO CLI/API; check/flip only at the console audience URL below.

2026-07-11: "This app is blocked" is per-ACCOUNT Google risk enforcement, not app state. [email protected] gets the hard no-bypass block page on a plain openid email calendar request, while a brand-new outsider account ([email protected], user 92) got the normal "Google hasn't verified this app -> Advanced -> proceed" warning and connected the same minute. Ruled out: include_granted_scopes inheritance (fresh incognito with all grants revoked still blocked), Advanced Protection, Family Link (his security tab shows neither), app-level flagging (outsider succeeded). Michael's account showed elevated-risk churn that day (new sign-ins, recovery email verified minutes before, 4 unresolved Security Checkup items, 9 unknown-device sessions). No developer-side workaround exists for a risk-blocked account+unverified-app combo; fixes are (a) Michael clears Security Checkup and retries after the account risk state settles, or (b) Google verification of the app (the durable fix; also lifts 100-user cap and scary warning). Before submitting verification: remove unused restricted scopes gmail.modify/gmail.send from the consent-screen declaration (nothing in the UI requests the gmail group yet) so verification stays sensitive-tier and avoids the CASA security assessment.

gcloud active account [email protected] has admin on this project (default gcloud project is forge-personal-assistant, NOT this one; always pass --project). See [[reference-gcloud-personal-project]].