You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
config push: changing auth.oauth_server.authorization_url_path fails with 400 (enabled and path must be sent together) #7087
Follow-up to #6367, which was closed as completed. On the new TypeScript CLI the diff half is fixed, but the push half still cannot change authorization_url_path on a project where the OAuth server is already enabled: the plan is correct, the request is rejected with a 400.
Version
supabase@next = 3.0.0-next.4 (via npx), Windows 11. Hosted project with oauth_server_enabled = true and oauth_server_authorization_path = "/oauth/consent".
Updating Auth service with config:
auth.oauth_server.authorization_url_path [update]
local: "/.lovable/oauth/consent"
remote: "/oauth/consent"
HTTP PATCH: https://api.supabase.com/v1/projects/<ref>/config/auth
ConfigPushAuthUpdateStatusError: unexpected status 400:
{"message":"Both OAUTH_SERVER_ENABLED and OAUTH_SERVER_AUTHORIZATION_PATH must be provided together when updating OAuth configuration"}
Nothing is written. config diff afterwards still reports the same update.
Expected
The path is updated. enabled is declared in the file and equals the remote value, so it is (correctly) not a change, but the Management API wants it in the same body as the path.
Likely cause
config push is diff-first and sends only changed fields. In apps/cli/src/commands/config/push/push.encoders.ts the three auth.oauth_server.* entries are plain scalar rows (source), not a required-together group like captcha, SMTP or the auth hooks, where an unchanged member is sent along with its current value. So a path-only change produces a body with oauth_server_authorization_path and no oauth_server_enabled.
Treating oauth_server_enabled + oauth_server_authorization_path as a required-together group should fix it. I have not checked whether the reverse case (changing only enabled) is rejected the same way; the error message suggests it is.
Why it matters
There is no CLI workaround that keeps the server up: the only way to make enabled part of the diff is to flip it, which takes the OAuth server down. On our project this path resets to /oauth/consent on its own from time to time (described in #6367), so being able to pin it from config.toml is the whole point.
Minor, related: with only authorization_url_path declared (no enabled = true), config diff lists the path under unmanaged and compares nothing. That follows ADR 0022, but the message does not say that declaring enabled = true is what makes it comparable.
I'd like to take this once it's marked open-for-contribution.
The cause is still there on develop: the three auth.oauth_server.* fields are plain scalar rows in push.encoders.ts, so a path-only change sends oauth_server_authorization_path without oauth_server_enabled.
Plan: an OAuth server container encoder next to encodeCaptchaContainer. When anything under auth.oauth_server changes, the body carries oauth_server_enabled from the local config and, when enabled, oauth_server_authorization_path resolved the same way captcha resolves its provider, so an unchanged member is sent with its current value. That covers both a path-only change and an enabled-only change. allow_dynamic_registration stays a scalar row, since the API error only ties the other two together. Encoder tests for both directions.
Activity
itz-puneet commentedon Oct 17, 2026
I'd like to take this once it's marked
open-for-contribution.The cause is still there on
develop: the threeauth.oauth_server.*fields are plain scalar rows inpush.encoders.ts, so a path-only change sendsoauth_server_authorization_pathwithoutoauth_server_enabled.Plan: an OAuth server container encoder next to
encodeCaptchaContainer. When anything underauth.oauth_serverchanges, the body carriesoauth_server_enabledfrom the local config and, when enabled,oauth_server_authorization_pathresolved the same way captcha resolves its provider, so an unchanged member is sent with its current value. That covers both a path-only change and anenabled-only change.allow_dynamic_registrationstays a scalar row, since the API error only ties the other two together. Encoder tests for both directions.