Context
On 2026-05-16 the Drive feature deployed with a misconfigured env: `REACT_APP_GOOGLE_API_KEY` was set to a value starting with `GOCSPX-`, which is the Google OAuth Client Secret format — not an API key (which starts with `AIza`).
Two bad consequences:
- The Picker rejected the credential ("API developer key is invalid")
- The Client Secret got inlined into the public JS bundle, briefly leaking it
What to do
Add a boot-time / build-time check that refuses to start (or fails CI) if any `REACT_APP_GOOGLE_API_KEY` value starts with `GOCSPX-`. The check belongs in:
- The web build step (catches at CI before it ships)
- Server startup (catches at deploy time even when CI is bypassed)
Pattern: a single guard function, e.g. `assertGoogleApiKeyShape(value)`, that throws on `GOCSPX-` prefix and warns on missing `AIza` prefix.
Why this is worth doing
The 30 minutes spent diagnosing the bad key value during the original Drive ship-week was preventable. A one-line check would have caught it at deploy.
Context
On 2026-05-16 the Drive feature deployed with a misconfigured env: `REACT_APP_GOOGLE_API_KEY` was set to a value starting with `GOCSPX-`, which is the Google OAuth Client Secret format — not an API key (which starts with `AIza`).
Two bad consequences:
What to do
Add a boot-time / build-time check that refuses to start (or fails CI) if any `REACT_APP_GOOGLE_API_KEY` value starts with `GOCSPX-`. The check belongs in:
Pattern: a single guard function, e.g. `assertGoogleApiKeyShape(value)`, that throws on `GOCSPX-` prefix and warns on missing `AIza` prefix.
Why this is worth doing
The 30 minutes spent diagnosing the bad key value during the original Drive ship-week was preventable. A one-line check would have caught it at deploy.