Supabase local auth gotchas: [auth.email] enable_signup=false kills magic-link login; config needs stop/start

In an invite-only app on the Supabase CLI stack, setting enable_signup = false under both [auth] and [auth.email] in config.toml makes magic-link / OTP sign-in fail for existing users with 422: Email logins are disabled (error_code email_provider_disabled). On top of that, config.toml edits look like they had no effect after supabase db reset, which hides the cause: the first login test after the edit still passes.

For an invite-only app, set [auth] enable_signup = false and keep [auth.email] enable_signup = true. Call signInWithOtp({ email, options: { shouldCreateUser: false } }). After editing config.toml, run supabase stop && supabase start and check with docker exec supabase_auth_<project> printenv GOTRUE_DISABLE_SIGNUP GOTRUE_EXTERNAL_EMAIL_ENABLED. Also add emailRedirectTo to additional_redirect_urls and make site_url the same origin as the dev server (localhost vs 127.0.0.1): otherwise GoTrue falls back to site_url, and the PKCE code-verifier cookie set on the other host is missing at the callback. Don't let a trigger on auth.users make every new user a member. Require invited_at or a flag in raw_app_meta_data (only the admin API can write it), and skip is_anonymous users, so access stays closed if sign-ups are ever re-enabled.

[auth.email] enable_signup maps to GOTRUE_EXTERNAL_EMAIL_ENABLED, which toggles the whole email provider, not just new sign-ups. Only [auth] enable_signup maps to GOTRUE_DISABLE_SIGNUP. supabase db reset restarts containers without regenerating the auth container's environment, so the auth config only changes on supabase stop && supabase start.