Expose GoTrue UpdatePasswordRequireCurrentPassword toggle in config.toml

[DaviDevMod]

TLDR: This issue has been filed by an AI agent and it's about Require current password when updating not being exposed in config.toml, which makes it unreasonably complicated to test locally what's going on in production.

Is your feature request related to a problem? Please describe.

GoTrue (supabase/auth) has two distinct password-change security toggles, both surfaced in the hosted dashboard under Authentication → Sign In / Providers → Email:

1. Secure password change → GoTrue UpdatePasswordRequireReauthentication (email-OTP reauth if the session is older than 24h). Exposed in config.toml as [auth.email] secure_password_change.
2. Require current password when updating → GoTrue UpdatePasswordRequireCurrentPassword (the user must supply their current password, verified server-side, to change it). Not exposed in config.toml at all.

Toggle #2 is the native current_password parameter on the /user PUT (internal/api/user.go in supabase/auth). The underlying env var GOTRUE_SECURITY_UPDATE_PASSWORD_REQUIRE_CURRENT_PASSWORD is a real, honored config field in GoTrue (internal/conf/configuration.go, split_words binding) — though it's currently undocumented in example.env, which only lists ..._REQUIRE_REAUTHENTICATION.

Because the CLI's buildGotrueEnv() (apps/cli-go/internal/start/start.go, ~line 1400) is a closed, hardcoded list that maps secure_password_change → GOTRUE_SECURITY_UPDATE_PASSWORD_REQUIRE_REAUTHENTICATION but never emits ..._REQUIRE_CURRENT_PASSWORD, the local supabase start stack cannot enable "Require current password when updating." There is no config.toml key for it, no [auth] arbitrary-env escape hatch, .env can't reach unbound GOTRUE_* vars, and (because the CLI drives the Docker Engine API directly via ContainerCreate/ContainerStart rather than docker compose up) a docker-compose.override.yml is not merged — so there is no local workaround either.

Impact: local/CI behavior cannot match a hosted project that has this toggle ON. The hosted dashboard enforces current-password server-side; the local stack silently doesn't. An app that relies on (or is tested against) that enforcement can't reproduce it locally.

Describe the solution you'd like

Expose the toggle in config.toml, mirroring the existing secure_password_change handling. Concretely (~2 edits + schema/test):

1. apps/cli-go/pkg/config/auth.go — add a sibling field next to SecurePasswordChange:

RequireCurrentPassword *bool `toml:"require_current_password" json:"requireCurrentPassword,omitempty"`

2. apps/cli-go/internal/start/start.go in buildGotrueEnv(), right after the ..._REQUIRE_REAUTHENTICATION line (~1400):

fmt.Sprintf("GOTRUE_SECURITY_UPDATE_PASSWORD_REQUIRE_CURRENT_PASSWORD=%v", utils.Config.Auth.Email.RequireCurrentPassword),

3. Regenerate the config schema + add a unit test.

Describe alternatives you've considered

• docker-compose.override.yml — does not apply. supabase start uses the Docker API directly (Docker.ContainerCreate/ContainerStart in apps/cli-go/internal/utils/docker.go), not docker compose up, so compose's override auto-merge never fires (verified: the CLI binary contains no docker-compose substrings; running containers carry no com.docker.compose.project.config_files label). Override files only work for the separate self-hosted docker compose up workflow.
• A general [auth] extra-env map — more flexible but a larger change; the targeted key above is the minimal fix and keeps parity with secure_password_change.

Additional context

• Supabase CLI version: 2.109.1.
• Bundled GoTrue: v2.190.0 (honors the env var when injected — verified against the running container).
• The env var GOTRUE_SECURITY_UPDATE_PASSWORD_REQUIRE_CURRENT_PASSWORD being absent from GoTrue's example.env may warrant a companion doc addition in supabase/auth.
• Naming note: the existing secure_password_change key is arguably misnamed (it controls reauth, not the current-password check), so I've proposed require_current_password to match the dashboard label — happy to use whatever name maintainers prefer.