config push sends [auth.sms] enable_confirmations un-negated as sms_autoconfirm, so hosted projects get the opposite of local
Los mantenedores suelen responder en 1 día
@7ttp ya está trabajando en esto.
Desde el 5/10/2026.
Evaluación
Este issue todavía no se ha evaluado.
Descripción
Affected area
Auth
Supabase CLI version
v2.98.0. The same code is on develop as of 2026-10-05.
Operating system
Ubuntu (GitHub Actions ubuntu-latest) for config push; macOS for supabase start.
Installation method
npm (via supabase/setup-cli@v3)
Command
supabase config push, compared with supabase start on the same config.toml.
Actual output
With this in supabase/config.toml:
[auth.email]
enable_confirmations = true
[auth.sms]
enable_confirmations = true
after supabase config push, the hosted project's GET /auth/v1/settings returns:
{ "mailer_autoconfirm": false, "phone_autoconfirm": true }
and the dashboard (Authentication > Sign In / Providers > Phone) shows "Enable phone confirmations" switched off.
So the email key means "require confirmation" and the identical SMS key means "skip confirmation". Locally, supabase start with the same file does require phone confirmation, so one config behaves in opposite ways on a local stack and on a hosted project.
Expected behavior
[auth.sms] enable_confirmations = true should set sms_autoconfirm = false on the hosted project, the way [auth.email] enable_confirmations = true sets mailer_autoconfirm = false, and the way supabase start already treats the SMS key.
Steps to reproduce
- Set
[auth.sms] enable_confirmations = trueinsupabase/config.toml. - Run
supabase link --project-ref <ref>andsupabase config push. - Run
curl https://<ref>.supabase.co/auth/v1/settings -H "apikey: <publishable key>". It returns"phone_autoconfirm": true, and the dashboard's Phone provider shows "Enable phone confirmations" off. - Run
supabase startwith the same file. The local auth container getsGOTRUE_SMS_AUTOCONFIRM=false.
Additional context
Cause. In pkg/config/auth.go (v2.98.0; apps/cli-go/pkg/config/auth.go on develop) the email mapping negates in both directions and the SMS mapping does not:
// email
body.MailerAutoconfirm = nullable.NewNullableWithValue(!e.EnableConfirmations) // L700
e.EnableConfirmations = !ValOrDefault(remoteConfig.MailerAutoconfirm, false) // L825
// sms
body.SmsAutoconfirm = nullable.NewNullableWithValue(s.EnableConfirmations) // L1121
s.EnableConfirmations = ValOrDefault(remoteConfig.SmsAutoconfirm, false) // L1170
internal/start/start.go negates both:
fmt.Sprintf("GOTRUE_MAILER_AUTOCONFIRM=%v", !utils.Config.Auth.Email.EnableConfirmations) // L1309
fmt.Sprintf("GOTRUE_SMS_AUTOCONFIRM=%v", !utils.Config.Auth.Sms.EnableConfirmations) // L1325
Because the read-back (L1170) is un-negated as well, the pushed value round-trips and config push has no diff to show for the key, so nothing flags it.
Why it matters. With sms_autoconfirm on, a phone number is marked confirmed without an OTP, both on signup and on PUT /user {phone}. A project that sets enable_confirmations = true believes it requires phone verification and does not.
Suggested fix. Negate L1121 and L1170 to match the email mapping. That flips the hosted value for any project that has worked around this by setting false, so it needs a release note.
History. Reported before as #4413, which was closed as not planned without a fix.
- Lenguaje dominante
- TypeScript
- Estrellas
- 2.4k
- Forks
- 531
- Merge medio
- 1 d 4 h
- PR fusionados (30 d)
- 351
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de supabase/cli
-
db schema declarative sync: no way to fail (non-zero exit) when the generated migration is destructiveQuizá libre de nuevo Un pull request para esta issue se cerró sin fusionarse. Abierto✨ Feature supabase/cli
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
Los mantenedores suelen responder en 1 día
-
stack: the HTTP gateway closes idle keep-alive connections after 5 s, so a client whose event loop is blocked gets ECONNRESET (`fetch failed`) on its next requestPosiblemente ocupada @7ttp la tomó hace 6 días. Abierto🐛 Bug supabase/cli
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
supabase/cli#6975 · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
📘 Docs supabase/cli
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
supabase/cli#6974 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Migration error caret is missing or misplaced when the statement contains multibyte charactersAbierto🐛 Bug supabase/cli
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
Los mantenedores suelen responder en 1 día
-
stack: a database helper stays behind as a `Created` container when readiness times out mid-createPosiblemente ocupada @just-some-random-pal la tomó hoy. Abierto🐛 Bug open-for-contribution supabase/cli
Dificultad 3/5 1-2 días Aptitud para principiantes 18/100
Los mantenedores suelen responder en 1 día
Todos los issues de supabase/cli
Issues similares
-
Mondriaan
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
knaw-huc/textannoviz#709 ·
Los mantenedores suelen responder en 1 día
-
Add: YRF Music NepalAbiertostreams:add
Dificultad 1/5 Menos de una hora Aptitud para principiantes 62/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
walletbeat/walletbeat#1558 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
hawk-digital-environments/HAWKI#438 ·
Los mantenedores suelen responder en 1 día
-
good first issue
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
OktoLabsAI/okto-pulse#114 ·
Los mantenedores suelen responder en 1 día