emailRedirectTo is ignored during signUp() confirmation email, but works correctly for resetPasswordForEmail()

[RamK07-2007]

Bug description

Using Supabase JS v2.110.7 on GitHub Pages.

My signup code is:

let { data, error } = await supabase.auth.signUp({
  email,
  password,
  options: {
    data: { nombre },
    emailRedirectTo: "https://<github-pages-site>/<repository>/"
  }
});

The request payload contains:

{
  "email": "...",
  "password": "...",
  "data": {
    "nombre": "..."
  },
  "email_redirect_to": "https://<github-pages-site>/<repository>/"
}

However, the confirmation email generated by Supabase always contains:

https://<project>.supabase.co/auth/v1/verify?...&redirect_to=https://<github-pages-site>/

instead of:

https://<github-pages-site>/<repository>/

The account is successfully created and the email is confirmed, but the redirect ignores the repository path.

Interestingly, password reset works correctly:

await supabase.auth.resetPasswordForEmail(email, {
  redirectTo: "https://<github-pages-site>/<repository>/"
});

and redirects to /repository/ as expected.

What I've already verified

• Supabase JS v2.110.7
• Site URL is https://<github-pages-site>/<repository>/
• Redirect URLs include https://<github-pages-site>/<repository>/
• The browser request payload contains the correct email_redirect_to
• window.location.href is https://<github-pages-site>/<repository>/
• The issue occurs both with supabase.auth.signUp() and a direct POST /auth/v1/signup request.

Email setup

I'm using the default Supabase email service and default email templates.

I do not have a custom SMTP server or a custom domain, so I cannot customize the confirmation email template. I'm relying entirely on the built-in Supabase email provider.

Project reference: bzmvnsgqtflpknnqadrj

Is there any known reason why signup confirmation emails ignore emailRedirectTo while password reset emails correctly respect redirectTo?

[Hallidayo]

Transferred from the supabase/supabase repo.

[zac343]

There is an open PR already linked from this issue, #2629, whose diagnosis matches the GitHub Pages symptom. Reading the current Auth source and that diff, the relevant selection order is:

1. an accepted explicit redirect_to from the query/header;
2. a valid HTTP Referer;
3. configured SiteURL.

On a cross-origin signup POST, strict-origin-when-cross-origin can reduce the Referer to https://user.github.io/. That origin can still be valid, so current Auth can select it before a Site URL containing /repository/.

Two checks should distinguish this cleanly:

• In DevTools, inspect the actual POST /auth/v1/signup?... URL, not only the payload pane. @supabase/auth-js 2.110.7 should serialize options.emailRedirectTo as the redirect_to query parameter. In the current reviewed Auth source, a direct POST that supplies only JSON email_redirect_to does not establish that explicit boundary.
• Record only whether the request Referer is origin-only or includes /repository/, then privately inspect the decoded host/path of redirect_to in one fresh confirmation URL. If the query is absent and the Referer is origin-only, the root redirect is explained before the template runs.

PR #2629 proposes both preferring a path-bearing Site URL over an origin-only Referer and accepting signup body fields, but it is still open, so I would not assume it is deployed until the hosted Auth version proves it.

I made a browser-local 108-state checklist for these request, Referer, Auth, template, and final-navigation boundaries: https://mailcheck.agentcartai.com/guides/supabase-signup-email-redirectto-path-ignored/?utm_source=github&utm_medium=issue_comment&utm_campaign=supabase_signup_redirect_path_2634

It asks for categorical outcomes only, not an email, project reference, confirmation link, token, API key, authorization header, or HAR.