email_verified is set to true during OTP email sign up before verifying the OTP code.

[TuureKaunisto]

Bug report

• I confirm this is a bug with Supabase, not with my own application.
• I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug

When signing up a new account with email OTP, already before the OTP code has been verified

• email_verified is set to true
• last_sign_in_at is set to current time
• confirmed_at is set to current time.

To Reproduce

supabase.auth.signInWithOtp({
    email,
    options: {
      shouldCreateUser: true,
      { data: { lang: 'en' } }, // setting email_verified: false here seems to have no effect
    },
  })

Expected behavior

email_verified should be false and last_sign_in_at should be null before supabase.auth.verifyOtp is called with the correct OTP code. When an email OTP code is verified, setting email_verified to true or saving some other flag or timestamp indicating that the user has proven they have access to the email is desireable.

System information

• Version of @supabase/ssr: 0.7.0
• Version of Node.js: 24.12.0

Currently, in the auth user records, the only way to know if a user has completed the OTP flow (proving they have access to the email) is to compare the created_at and last_sign_in_at timestamps. If the difference is really small, the user has most likely not signed in.

Also, why is email_verified stored in raw_user_meta_data? Should it not be more of an internal property and therefore not in the same column with user defined metadata?

[Vivek11004]

Hi @TuureKaunisto, thanks for the clear repro steps.

I'd like to dig into this — my initial read is that the signup handler is setting email_verified/confirmed_at/last_sign_in_at at user-creation time rather than at successful verifyOtp time. Before I open a PR, I want to check:

1. Whether magic-link and phone-OTP signup flows share this same code path (so a fix doesn't regress them)
2. Whether email_verified being in raw_user_meta_data vs. a dedicated internal column is intentional or itself part of the bug

I'll trace the relevant code in supabase/auth and report back what I find before proposing a fix. Let me know if a maintainer is already looking into this or has thoughts on the right approach.