fix(cli): honor local auth overrides (CLI-2349)

[7ttp]

TL;DR

fixes seed buckets, db reset and storage --local getting rejected by the local storage gateway when SUPABASE_AUTH_JWT_SECRET or SUPABASE_AUTH_SERVICE_ROLE_KEY comes from supabase/.env or is stored as an encrypted: value...

whats broken?

supabase start resolves auth.jwt_secret and auth.service_role_key through the env/dotenv override and decrypt path, but the shared storage credentials resolver reads the two vars from the shell env only and uses an encrypted: value as literal key material. a key set in supabase/.env

starts the stack with one service-role key while seed buckets and storage ls sign with another, and the gateway returns 401. on db reset that lands after the migrations already ran...

now fixed by:

resolving both fields in resolveLocalServiceRoleKey through the same
legacyEnvOverride -> legacyDecryptAuthSecret composition the start/status/stop resolver already applies to them, over the dotenv map the resolver already loads. the same checks now also run on the seed buckets no-op path (nothing configured to seed)
which previously exited 0 without reading [auth]: a short auth.jwt_secret or an undecryptable encrypted: value now exits 1 there with the config error start already raises. --linked is untouched.

ref:

• closes: CLI-2349
• extends: fix(cli): honor SUPABASE_API_* overrides (CLI-2318) #6467

[github-actions]

Supabase CLI preview

npx --yes https://pkg.pr.new/supabase/cli/supabase@4f113052c62c735781e80bfcc16a1171e4065381

Preview package for commit 4f11305.

[github-actions]

🤖 AI Review

All five Claude findings are confirmed after reading the cited code; Codex reported no findings. Two minor findings concern local service-role token consistency, one concerns incomplete side-effect documentation, and two are polish issues. The documentation finding was narrowed because db reset does not itself exercise the cited shadow-cache path. No critical or major issues were identified.

Findings

Severity	Location	Category	Sources	Claim
🟡 MINOR	apps/cli/src/command-internal/legacy-storage-credentials.ts:287	correctness	claude	When no service-role key is configured, the local Storage credential resolver generates a token with a different claim shape from the service-role token resolved for the running stack and displayed by status.
🟡 MINOR	apps/cli/src/commands/db/reset/SIDE_EFFECTS.md:143	documentation	claude	The environment-variable row incorrectly limits SUPABASE_AUTH_JWT_SECRET and SUPABASE_AUTH_SERVICE_ROLE_KEY to bucket seeding even though they also affect local database recreation and setup.
🟡 MINOR	apps/cli/src/command-internal/db-bootstrap/reset-local-database.ts:234	consistency	claude	With auth.signing_keys_path configured and no explicit service-role key, db reset bucket seeding passes raw config and therefore derives a symmetric key instead of reusing the asymmetric values.serviceRoleKey resolved for the running stack.
⚪ NIT	apps/cli/src/command-internal/legacy-storage-credentials.ts:257	maintainability	claude	resolveLocalServiceRoleKey duplicates the auth member shape instead of referencing LegacyStorageConfigView["auth"], allowing the declarations to drift.
⚪ NIT	apps/cli/src/commands/seed/buckets/buckets.integration.test.ts:239	test-isolation	claude	The test comment says all ambient DOTENV_PRIVATE_KEY* variables are unset, but the setup only clears DOTENV_PRIVATE_KEY and DOTENV_PRIVATE_KEY_LOCAL.

Findings outside the diff

• 🟡 MINOR apps/cli/src/command-internal/db-bootstrap/reset-local-database.ts:234 — With auth.signing_keys_path configured and no explicit service-role key, db reset bucket seeding passes raw config and therefore derives a symmetric key instead of reusing the asymmetric values.serviceRoleKey resolved for the running stack.

Stats

Claude findings: 5 · Codex findings: 0 · Confirmed: 5 · Refuted: 0 · Uncertain: 0

---

Models: claude-opus-5 + gpt-5.6-sol · Trigger: auto · Workflow run

This review runs once per PR. A maintainer can request another with a /ai-review comment.