DEV Community: VibeFix

Lovable login loop: users sign up, then land back on the login page (4 causes)

VibeFix — Sun, 01 Nov 2026 09:46:25 +0000

Someone signs up to your app, and instead of getting in they end up back on the sign-up or login page. Or they try to log in and get an error. They try again, it happens again, and they leave.

You don't see it, because you're already signed in. Here are the usual reasons in apps built with AI tools, and how to fix each one.

First, find out which one it is

Open your live site in a private window, ideally on your phone, and sign up with an email address you've never used on the app. Then note:

Did a confirmation email arrive? If not, see Sign-up email not arriving.
Where did the link in that email take you? If it opened localhost or your preview, see Confirmation link opens localhost.
What does the screen say when you try to log in? Write down the exact error text. It tells you which reason below applies.

Reason 1: the account isn't confirmed yet

Most sign-in services make new people confirm their email before they can sign in. Supabase's docs say that on hosted projects "this is true by default". Lovable's docs say the same: with auto-confirm off, users "must verify the address before signing in".

So if the confirmation email never arrives, or the person tries to log in before clicking it, the login is refused (Supabase's error code is email_not_confirmed), and to them it looks like a loop.

Fix: make the confirmation email reliable first; this guide covers it. For someone already stuck, Lovable's docs note that "signing in again does not resend it". They get a new email by signing up again with the same address. On Lovable's built-in backend you can also add them under More → Users → Add user → Create new user, and accounts added that way are confirmed automatically.

Reason 2: the live address isn't on the allowed list

After sign-up or sign-in, the sign-in service sends people back to your app, but only to addresses on its allowed list. Otherwise it uses its default address, which for Supabase starts as localhost:3000. Lovable's docs put it plainly: "If sign-in works in preview but breaks on your published app or custom domain, these URLs are usually the reason."

Fix:

Supabase (including Bolt and most AI tools that use it): open Authentication → URL Configuration. Set Site URL to your live address, and add every live address under Redirect URLs (with and without www).
Lovable: ask Lovable in the chat to update them for your domain, or add your address under Auth settings → Advanced → Redirect URLs. If the app uses your own Supabase project, use the Supabase steps above.
Firebase: if sign-in fails only on your live domain, check that the domain is on the list of authorized domains in Authentication settings, and add it if it's missing.

Reason 3: the app never finishes signing the person in

Some apps (especially ones with server-side pages) use a sign-in flow where the email link brings back a one-time code, and the app has to swap that code for a signed-in session on the page it lands on. Supabase's docs say that code "can only be exchanged for an access token once", is valid for 5 minutes, and the swap "must be initiated on the same browser and device where the flow was started".

So if the landing page doesn't do the swap, or the person opens the email link in a different browser (for example inside their email app), they arrive signed out and are sent back to login.

Fix: paste this into your builder:

New users sign up but end up back on the login page instead of signed in. Check the page the sign-up and sign-in links return to: it must turn the code in the link into a signed-in session, then send the person into the app. Also check that the session is kept after the next page load. Don't change anything else. Then tell me how to test it with a fresh email on the live site, opening the email link on the same phone.

Reason 4: sign-up is switched off

It sounds obvious, but it happens. Supabase has an Allow new users to sign up setting, and Lovable has Disable sign-up. With sign-up off, only existing users can get in, and Supabase answers new sign-ups with signup_disabled.

Fix: check that setting in your sign-in service and turn new sign-ups back on.

Still stuck in the loop?

App broke after you published it? Our AI agent fixes it in your code, then tests your live app again so you see the result yourself. The first check is free. vibe-fixer.com

When did you last sign up to your own app the way a stranger would, in a private window on your phone?

Lovable, Bolt, Replit, Base44, v0, Supabase and Firebase are trademarks of their owners.

Originally published at vibe-fixer.com. I'm building VibeFix, an AI agent that finds what is breaking your live app, fixes it in your code and re-checks it.

Let Claude check your live app like a new user

VibeFix — Thu, 29 Oct 2026 11:09:41 +0000

Your app works for you. You're signed in, your customers aren't. The first screen a brand-new customer hits is the one you never see.

VibeFix now works inside Claude. The same server can be added to Cursor and Codex too; their setup is below, but we haven't finished a test run in those two yet. When your app breaks, ask your AI tool to check the live app. It calls VibeFix, and our AI agent signs up like a new user and shows you, with a screenshot, whether your app breaks for them. It only checks your own app, and only when you say yes.

Here is the setup for each tool.

Claude Code

Connect the server:

claude mcp add --transport http vibefix https://vibe-fixer.com/mcp

Or install the server and the skill together as a plugin:

claude plugin marketplace add yos88da/vibefix-mcp && claude plugin install vibefix@vibefix

Claude (desktop and web)

Go to Customize, Connectors, press +, then Add custom connector. Paste https://vibe-fixer.com/mcp and press Add. VibeFix is also listed in Claude's connector directory.

Cursor

Add the server to ~/.cursor/mcp.json:

{ "mcpServers": { "vibefix": { "url": "https://vibe-fixer.com/mcp" } } }

Then add the project rule that tells Cursor when to call it:

curl -fsSL https://raw.githubusercontent.com/yos88da/vibefix-mcp/main/agent-rules/cursor/vibefix.mdc --create-dirs -o .cursor/rules/vibefix.mdc

Codex

codex mcp add vibefix --url https://vibe-fixer.com/mcp
codex mcp login vibefix

And the AGENTS.md section that tells Codex when to call it:

curl -fsSL https://raw.githubusercontent.com/yos88da/vibefix-mcp/main/agent-rules/AGENTS.md >> AGENTS.md

Any agent that takes skills

npx skills add yos88da/vibefix-mcp

What to ask

"Check my live app at https://example.com like a brand-new user."

The skill also tells your agent to offer a check when you say your deployed app is broken, or right after you publish a change.

Try it

App broke after you published it? Our AI agent fixes it in your code, then tests your live app again so you see the result yourself. The first check is free. vibe-fixer.com/tools

Which tool do you build with, and would you let it test your live app the way a stranger would?

Claude, Cursor and Codex are trademarks of their owners. VibeFix is independent and is not affiliated with or endorsed by them.

I'm building VibeFix.

"new row violates row-level security policy": why data won't save in Supabase

VibeFix — Mon, 26 Oct 2026 09:00:44 +0000

A user fills in a form, presses Save, and nothing happens. The console or logs show "new row violates row-level security policy for table", followed by the table name. A public example: new row violates row-level security policy for table "players_secure" (supabase/postgres #1708).

Row-level security (RLS) is a set of rules on each table about who may read or write which rows. Supabase says that once RLS is enabled, "no data is accessible through the API when using a publishable key, until you create policies." PostgreSQL says inserted rows that do not pass the policy "will result in a policy violation error, and the entire INSERT command will be aborted."

So the database is protecting the table as designed. The fix is a policy that lets the right person write the right row, not switching RLS off. You can add policies in the Supabase SQL editor; replace the table and column names with yours.

1. There is no INSERT policy on the table

A table may have a policy for reading but none for adding rows.

Fix: add an insert policy for signed-in users that checks the row belongs to them, adapted from Supabase's profiles example:

create policy "Users can create their own rows"
on public.your_table for insert to authenticated
with check ( (select auth.uid()) = user_id );

Then save again from the app while signed in.

Source: Supabase: Row Level Security

2. The row does not carry the signed-in user's id

The policy compares a column (such as user_id) with the signed-in user. If the app leaves that column empty, or fills it with another id, the check fails.

Fix: in the code that saves, set user_id to the id of the signed-in user from the current session, and make sure the column name in the policy matches the column the app fills.

Source: Supabase: Row Level Security

3. The person is not signed in when the save runs

Supabase says that when a request has no authenticated user, auth.uid() returns null, so a policy like auth.uid() = user_id silently fails for them. It recommends auth.uid() IS NOT NULL AND auth.uid() = user_id. This happens when a form is used before sign-in, or when the session has expired.

Fix:

Require sign-in before the screen that saves, or wait until the session exists.
If the form is meant for visitors who are not signed in (a contact form, for example), write a separate insert policy for the anon role that allows only that table and only the fields it needs.

Source: Supabase: Row Level Security

4. The app asks for the new row back, and there is no SELECT policy

PostgreSQL says that if an insert returns the new row, "any newly inserted or updated rows from the relation must satisfy the relation's SELECT policies", and otherwise an error is thrown. In supabase-js this is an insert followed by .select().

Fix: add a select policy so people can read their own rows, or stop asking for the row back if the app does not need it.

create policy "Users can view their own rows"
on public.your_table for select to authenticated
using ( (select auth.uid()) = user_id );

Sources: PostgreSQL: CREATE POLICY · Supabase: Row Level Security

5. It is an upsert or an update

An upsert needs more than an insert policy. PostgreSQL checks the SELECT policies for an insert with ON CONFLICT DO UPDATE, and the UPDATE policy applies to its update part. Supabase also warns that without a SELECT policy, an UPDATE "will not work as expected."

Fix: add an update policy for the owner of the row, with both using and with check comparing (select auth.uid()) with user_id, and make sure a select policy exists too (cause 4).

Sources: PostgreSQL: CREATE POLICY · Supabase: Row Level Security

6. It is a file upload to Supabase Storage

Uploads are rows in the storage.objects table. Supabase says "by default Storage does not allow any uploads to buckets without RLS policies", and that the only policy needed for uploading is INSERT on storage.objects. Overwriting with upsert also needs SELECT and UPDATE.

Fix: add an insert policy on storage.objects for the authenticated role, limited to your bucket (Supabase's example checks bucket_id and the folder with storage.foldername(name)). If the app overwrites files, add select and update policies as well.

Source: Supabase Storage: Access control

Why you can't see it yourself

You're signed in, your customers aren't. You test as the owner, often from the builder, signed in, with rows that already exist. A brand-new account, or a visitor who is not signed in, is governed by the rules you never tried.

FAQ

Can I just turn row-level security off? The error disappears because the table becomes open to anyone with your public key, which is the opposite of what you want. Supabase also says never to use the secret or service_role key in the browser to get around it, because it bypasses RLS. Write the missing policy instead.

The same insert works in the SQL editor but fails from the app. Why? A public report (supabase/postgres #1708) describes exactly that. The app sends requests as the anon or authenticated role, and policies are written for those roles, so test policies as the role your app uses.

Fixed it? Prove a real stranger gets in

After the fix, the proof is a brand-new account saving its first row on your live app, and not seeing anyone else's. Your own account cannot show that, because it is not new. Your AI reads your code. VibeFix signs up like a stranger.

Still broken?

App broke after you published it? Our AI agent fixes it in your code, then tests your live app again so you see the result yourself. The first check is free. vibe-fixer.com

VibeFix is independent. Supabase is a trademark of its owner.

Have you tried saving a row from a brand-new account on your live app, not your own?

VibeFix is independent. Lovable is a trademark of its owner.

Originally published at vibe-fixer.com. I'm building VibeFix, an AI agent that finds what is breaking your live app, fixes it in your code and re-checks it.

Lovable publish not working: what is failing, and what a visitor sees

VibeFix — Sun, 25 Oct 2026 09:13:17 +0000

Your app says it published, and a visitor still sees an old version, a locked page or a sign-in that fails. Or the Publish button itself stops with a "Publishing failed" banner. "Lovable publish not working" covers both, and they have different fixes.

The preview and the published app are separate. Lovable says only publishing puts your app on a public URL, and later changes are not pushed live on their own. Hosting serves the pages; the backend handles data and sign-in. Either side can be the one failing.

When the Publish button fails

The banner names one of six categories and offers the matching action.

Temporary issue. A short-lived problem such as a timeout or a rate limit on a connected service. Click Try again; Lovable says retries usually succeed.
Error in your app. A build error or an edge function that could not be deployed: the app ran in the preview but cannot be built for production. Click Try to fix, or describe the issue in the project chat, then publish again.
Configuration issue. A problem in the project setup, such as a file too large to include. Click Try to fix, then publish again.
External connection or secret. Something outside the project, such as an expired Supabase connection or a connected service at its plan limits. Reconnect the integration or update its plan or quota, then click Try again.
Database change conflicts with existing data. Click Ask the assistant to help and go through the fix with it, since it touches real data.
Internal error. Lovable's banner puts this one on its own side. Try again after a few minutes; if it keeps failing, contact Lovable support with your project link.

Source: Lovable: Publish your project

When publishing is blocked, not failing

Some states stop publishing without a failure:

"Fix security issues to publish": the workspace blocks publishing with critical findings. Resolve them, then publish.
"Publish requires approval" (an Enterprise workspace policy): select Request approval and write a short note for the approvers.
"You don't have permission to publish this project": publishing needs editor access or above.

Source: Lovable: Publish your project

When it published, but visitors still have a problem

They see the old version. A dot on the Publish button means the project has changes newer than the live version. Open the Publish dialog and click Publish changes.

Nobody else can open it. On Free and Pro, visibility is Public by default with an Invite only option; Business and Enterprise have Public, Workspace and Custom. Set the audience to Public in the Publish dialog, then click Publish changes so it takes effect.

Pages load, but sign-in and data fail. The backend may be paused. Lovable says pausing affects the app's data and logic, not page hosting, and a paused backend may not restart on its own. Go to More, Database and click Wake up on the paused card.

The custom domain is not Live. Until it shows Live, visitors on that address do not reach the app. Open Project, Settings, Domains and read the status; if it shows Offline, click Recover, review the DNS records shown and update them at your DNS provider.

It is down for everyone. Check status.lovable.dev for incidents, open the Publish dialog to confirm the project is still published, and check your email for an inactivity notice (Free-plan projects can be unpublished for inactivity). If visitors see "App temporarily unavailable", the Free-plan request limit was reached: newer apps are limited to 1,000 server requests per project per 10 seconds, and visitors can try again after a minute.

Sources: Lovable: How Lovable hosts your app · Lovable: Custom domains

Why you can't see it yourself

You're signed in, your customers aren't. In the editor you see the banner and the preview, signed in as an editor, with an awake backend. A visitor sees only the published address and meets whatever the published side actually does.

FAQ

Why can't visitors see my latest changes? Lovable does not push later edits live automatically. A dot on the Publish button means there are newer changes; click Publish changes.

Does a paused backend take my site down? No. Pages still load, but data and sign-in fail until you click Wake up under More, Database.

Published? Prove a real stranger gets in

A published app that works from your own account proves nothing about a new visitor. Your AI reads your code. VibeFix signs up like a stranger.

Still broken?

App broke after you published it? Our AI agent fixes it in your code, then tests your live app again so you see the result yourself. The first check is free. vibe-fixer.com

VibeFix is independent. Lovable and Supabase are trademarks of their owners.

Which one got you: the Publish banner, or a visitor seeing something you never saw in the editor?

Originally published at vibe-fixer.com. I'm building VibeFix, an AI agent that finds what is breaking your live app, fixes it in your code and re-checks it.

AuthApiError: Email not confirmed in Supabase: why new users can't sign in

VibeFix — Sat, 24 Oct 2026 08:00:11 +0000

A new person signs up, tries to sign in, and your app says "Email not confirmed". In code it comes back as an AuthApiError with the code email_not_confirmed; public reports show the raw response as {"code":"email_not_confirmed","message":"Email not confirmed"} (Supabase issue #29632). The account exists, but the person is locked out of it.

Supabase's error reference describes it as: "Signing in is not allowed for this user as the email address is not confirmed." The project is doing what it was told. With Confirm email on, users "will need to confirm their email address before signing in for the first time", and on hosted Supabase projects it is on by default. On self-hosted projects and in local development it is off by default, which is why an app can behave differently on a laptop than live.

So the real question is why this person is still unconfirmed. Supabase also advises identifying errors by error.code, not by matching the message text. Here are six reasons, in the order to check them.

1. The confirmation email was never sent or never arrived

Supabase's default email service only delivers to addresses on your project's team, at 2 messages per hour, and "is not meant for production use".

Fix:

Open your project's Auth logs and look for an error at the time of the sign-up. Supabase names this as the first step for undelivered auth emails.
If you are on the default email service, set up your own SMTP provider and enable custom SMTP in the Authentication settings. Supabase lists Resend, AWS SES, Postmark, Twilio SendGrid, ZeptoMail and Brevo as examples.
Set up SPF, DKIM and DMARC for the sending domain. Supabase recommends this for deliverability.

Sources: Supabase: Send emails with custom SMTP · Supabase troubleshooting: Not receiving Auth emails

2. The email arrived, but the link was already used up

Supabase documents that some email providers' security features prefetch links in incoming emails. The one-time link is consumed before the person clicks it; they see "Token has expired or is invalid" and stay unconfirmed.

Fix:

Open the Email Templates page in the dashboard and edit the Confirm signup template.
Choose one of Supabase's two documented options: send a one-time code by putting {{ .Token }} in the template and verify it with supabase.auth.verifyOtp, or link to a page in your app with a button that opens the real confirmation link.
Send the affected person a new confirmation email (see cause 4).

Source: Supabase: Email templates

3. The link sent them to localhost or a page that does not finish the job

Supabase's Site URL defaults to http://localhost:3000, and it is used whenever the app does not name an approved redirect. With the PKCE flow, Supabase's template sends the person to {{ .SiteURL }}/auth/confirm?token_hash=..., so confirmation only completes if that page exists on your live app.

Fix:

Open URL Configuration in the dashboard and change the Site URL from localhost to your live address.
Add your live address to the Redirect URLs list, for example https://yourapp.com/**.
In the sign-up call, pass options: { emailRedirectTo: 'https://yourapp.com/welcome' }. The address must be on the Redirect URLs list.
If your template uses a token-hash link, make sure your live app has the page it points to.

Sources: Supabase: Redirect URLs · Supabase: Password-based auth

4. They tried to sign in again, expecting a new email

Signing in does not send a new confirmation email. Someone who keeps trying only gets the same refusal. Lovable's documentation says it plainly: "signing in again does not resend it".

Fix:

Catch email_not_confirmed in your sign-in screen and show a "Resend confirmation email" button instead of a generic error.
Have the button call supabase.auth.resend({ type: 'signup', email, options: { emailRedirectTo } }).
Disable the button for at least 60 seconds after each send. Supabase's default allows one signup confirmation request per user per 60 seconds.
On an app on Lovable's built-in backend without such a button, Lovable's documented route is for the person to sign up again with the same address.

Sources: Supabase JavaScript reference: resend() · Supabase: Rate limits · Lovable: Email authentication

5. The account was created outside the normal sign-up

Users created with the admin API (auth.admin.createUser) without email_confirm: true can be left unconfirmed, and then hit the same error. Public reports describe this even after Confirm email was switched off (#29632).

Fix:

Confirm the account on the server with supabase.auth.admin.updateUserById(id, { email_confirm: true }). Supabase says this function "should only be called on a server", and never with the service_role key in the browser.
On Lovable's built-in backend, accounts you create under More, Users, Add user, Create new user are confirmed automatically.

Sources: Supabase: auth.admin.updateUserById() · Lovable: Email authentication

6. The app assumes people are signed in right after sign-up

Confirmation is one switch for the whole project. If your screens send a new person straight into the app after sign-up, the next sign-in attempt meets this error.

Fix:

Decide whether you want confirmation. Supabase keeps it on by default for hosted projects. In Lovable the matching setting is Auto-confirm email, and Lovable recommends keeping confirmation on for live apps.
If confirmation stays on, show a "check your email" screen after sign-up instead of opening the app.
Test the full path with a brand-new address, not your own account.

Sources: Supabase: General configuration · Supabase: Password-based auth

Why you can't see it yourself

You're signed in, your customers aren't. You confirmed your own account long ago, from an address that is on the team. You never sit where a new person sits: signed up, unconfirmed, waiting for an email that may never come.

FAQ

I switched off "Confirm email", but users still get "Email not confirmed". Why? People report this on Supabase's GitHub, for example #29632 and #5113. For an account that is already stuck, confirm that account: send a new confirmation email with resend(), or confirm it on the server with updateUserById.

Can people use the app before confirming their email? Only by switching confirmation off for the whole project. A request for a middle ground (supabase/auth #1494) was closed in 2024, with anonymous sign-in suggested as the alternative.

Fixed it? Prove a real stranger gets in

The test that matters is a brand-new address signing up, getting the email, clicking the link and signing in on your live app. Your own account cannot show that, because it is not new. Your AI reads your code. VibeFix signs up like a stranger.

Still broken?

App broke after you published it? Our AI agent fixes it in your code, then tests your live app again so you see the result yourself. The first check is free. vibe-fixer.com

VibeFix is independent. Supabase and Lovable are trademarks of their owners.

Does your sign-in screen tell an unconfirmed user what to do next, or does it only show the error?

Originally published at vibe-fixer.com. I'm building VibeFix, an AI agent that finds what is breaking your live app, fixes it in your code and re-checks it.

Supabase "Error sending confirmation email" (500): what it means and the 6 causes

VibeFix — Fri, 23 Oct 2026 08:00:11 +0000

A new person signs up and your app shows "Error sending confirmation email" instead of letting them in. Public reports show it as a 500 with the code unexpected_failure: {"code":"unexpected_failure","message":"Error sending confirmation email"} (Supabase discussion #29703; also #36181). Password reset can fail the same way with "Error sending recovery email".

The 500 alone does not say why. The reason is written in one place, and most people never open it.

What the error means

With Confirm email on, Supabase Auth has to hand a message to an email server before the sign-up can finish. This error means that hand-over failed. Supabase's error reference says a 500 indicates the Auth service is degraded and "most often it points to issues in your database setup", and unexpected_failure means "Auth service is degraded or a bug is present, without a specific reason."

The reason is in your project's Auth logs. In both public threads above, the first answer from a Supabase repository collaborator was the same: check the Auth logs for the message from the SMTP provider.

0. Read the real error first

Every cause below leaves a different line in the logs, so this decides which fix applies.

In the Supabase dashboard, open the Auth logs and find the entry at the time of the failed sign-up.
If the line mentions your SMTP provider (authentication failed, sender not allowed, certificate, connection), go to cause 2 or 3.
If it mentions a database object, trigger or relation, the problem is in the database ("Database error saving new user" is the usual sign).
If you send email through a provider, check that provider's own logs next. Supabase names them as the next place to look.

Source: Supabase troubleshooting: Not receiving Auth emails

1. You are on the default email service and the address is not on your team

Unless you configure your own SMTP server, Supabase Auth "will refuse to deliver messages to addresses that are not part of the project's team". The error code reference lists email_address_not_authorized: "Emails can only be sent to members in your Supabase organization." The default service also allows 2 messages per hour and is "not meant for production use". Every address you test with is on the team. Every stranger is not.

Fix:

Choose an email provider. Supabase names Resend, AWS SES, Postmark, Twilio SendGrid, ZeptoMail and Brevo as examples.
From the provider, copy the SMTP host, port, username and password, and decide the sender address and sender name.
In the Supabase dashboard, open the Authentication settings, enable custom SMTP and enter those values.
Sign up again with an address that is not on your team.

Source: Supabase: Send emails with custom SMTP

2. Custom SMTP is on, but a setting is wrong

Supabase says "handover issues can occur due to misconfiguration of the custom SMTP provider".

Fix:

Compare each field in Supabase (host, port, username, password, sender address) with the values on your provider's SMTP page, character for character.
Use the SMTP username and password the provider issued, not your login to the provider's website.
Make sure the sender address is one your provider allows you to send from.
Save, then sign up again with a new address and read the Auth logs.

Source: Supabase: Send emails with custom SMTP

3. The sender domain is not verified with your provider

Email providers ask you to verify the domain you send from. In discussion #29703, the fix was adding the provider's DNS records: "adding the DNS for resend did the trick."

Fix:

In your email provider, add your sending domain and copy the DNS records it gives you.
Add those records at your domain's DNS host and wait for the provider to show the domain as verified.
Set up SPF, DKIM and DMARC for that domain, which Supabase recommends for deliverability.
Use a sender address on that verified domain in the Supabase SMTP settings.

Source: Supabase: Send emails with custom SMTP

4. A Send Email hook does not answer

If your project sends auth emails through a Send Email hook, Supabase lists hook_timeout: "Unable to reach hook within maximum time allocated." Only projects that use a hook can have this cause.

Fix:

Check that the hook's endpoint or function is deployed and reachable.
Look at the hook's own logs for errors or slow responses at the time of the failure.
If you do not need the hook, switch back to SMTP sending.

Source: Supabase: Auth error codes

5. A sending limit was reached

When a limit is the cause, the message is usually different: "email rate limit exceeded", with status 429. With custom SMTP, Supabase starts you at 30 messages per hour; raise it on the Rate Limits page of the Authentication section once your own SMTP is set up.

Sources: Supabase: Rate limits · Supabase: Send emails with custom SMTP

6. Supabase Auth itself is degraded

The one that is not yours to change. The Auth logs show no provider or database error. Check Supabase's system status page for an incident, retry after it is resolved, then sign up with a new address.

Source: Supabase: Auth error codes

Why you can't see it yourself

You're signed in, your customers aren't. Your own address is on the team, so the default sender accepts it. You sign up once, so you never hit an hourly limit. A custom provider can accept the address you tested and still refuse the next one. Only a brand-new address from outside the team meets these causes.

FAQ

It worked yesterday. Why did it suddenly stop? This exact question was asked in discussion #36181. The answer was to check the Auth log for an error from the SMTP provider. Read that line before changing anything.

Did the sign-up still create the user? Check the Users list in your Supabase dashboard. If the user exists but is unconfirmed, they will later meet "Email not confirmed". Once email works, send a new confirmation with resend().

Can I just turn off email confirmation? Sign-ups will no longer send that email, but anyone can then register with an address they do not own, and password reset emails still need a working sender.

Fixed it? Prove a real stranger gets in

After the fix, prove it with an address that is not on your team: it must get the email, confirm and sign in. Your own account cannot show that, because it is not new. Your AI reads your code. VibeFix signs up like a stranger.

Still broken?

App broke after you published it? Our AI agent fixes it in your code, then tests your live app again so you see the result yourself. The first check is free. vibe-fixer.com

VibeFix is independent. Supabase, Resend, AWS SES, Postmark, Twilio SendGrid, ZeptoMail and Brevo are trademarks of their owners.

When this error hit your app, what did the Auth log line actually say?

VibeFix is independent. Lovable is a trademark of its owner.

Originally published at vibe-fixer.com. I'm building VibeFix, an AI agent that finds what is breaking your live app, fixes it in your code and re-checks it.

Supabase confirmation email not sending: why new users never get it

VibeFix — Thu, 22 Oct 2026 18:49:38 +0000

It worked every time you tried it. Then real people sign up, wait for the confirmation email, and nothing comes. Supabase's built-in sender only delivers to addresses on your project's team, sends 2 messages an hour, and is not meant for production. Your own address is on the team. A stranger's is not.

Sign-up only finishes when the person clicks the link or enters the code in that email. Whatever sends your app's emails decides who gets them, how many go out per hour and whether they land in the inbox. The default senders are made for trying things out, not for strangers arriving from an ad or a post.

Here are the seven causes, and the fix for each.

1. Supabase's default sender only delivers to your team

Unless you set up your own SMTP server, Supabase only sends to addresses that are part of the project's team. Everyone else's message fails (the error code is email_address_not_authorized).

Fix:

From your email provider, get the SMTP host, port, user and password, and choose a From address on your own domain (for example no-reply@yourdomain.com).
In the Supabase dashboard, open the Authentication settings page and enable custom SMTP.
Enter the host, port, user, password and From address, and save.
Sign up with an address that is not on your team and confirm the email arrives.

Source: Supabase: Send emails with custom SMTP

2. The hourly email limit was reached

The default service sends 2 messages per hour for the whole project. Once custom SMTP is saved, Supabase starts you at 30 messages per hour. A few sign-ups close together, or a launch day, use that up and later people get nothing.

Fix:

Set up custom SMTP first (cause 1). Supabase says the email limit can be configured once you use custom SMTP or a Send Email hook.
Open Authentication, Rate Limits in the dashboard.
Raise the email limit to fit the sign-ups you expect, within what your email provider allows.

Sources: Supabase: Send emails with custom SMTP · Supabase: Rate limits

3. Your own sender is connected, but the hand-over fails or mail lands in spam

Supabase hands the message to your provider. A wrong setting stops that hand-over; after it, Supabase says it "has no control over email delivery". Providers keep suppression lists of addresses that bounced before, and recipients' mail filters can quarantine or spam the message.

Fix:

Check your project's Auth logs first; a failed hand-over shows there.
Then check your email provider's own logs for blocked or suppressed addresses.
With your provider, set up DKIM, DMARC and SPF for the sending domain.
Send from your own domain, and keep sign-in emails separate from marketing emails.

Sources: Supabase troubleshooting: Not receiving Auth emails · Supabase: Send emails with custom SMTP

4. Lovable: the project's hourly email cap

Apps on Lovable's built-in backend have a per-project "Rate limit for sending emails" that caps sign-in emails per hour; Lovable says it is the first thing to check when confirmations stop arriving after many sign-ups. Lovable's Emails feature also limits authentication emails per workspace per hour (Pro 500, Business 3,000, Enterprise 10,000), and at a workspace limit new emails are rejected until the hour resets.

Fix:

Open More, Users, Settings, Email, and look under Advanced for "Rate limit for sending emails".
Raise it to match your expected sign-ups. Lovable notes that raising the sending limit needs managed email or a verified custom domain first.
Open More, Emails to see the workspace usage; Lovable shows a warning at 80% of a limit.

Sources: Lovable: Email authentication for your app · Lovable: Send branded emails from your own domain

5. Lovable: emails from a new domain land in spam

Lovable says emails from new domains often land in spam. On a paid workspace you can send sign-in emails from your own domain, with Lovable handling the DNS, SPF, DKIM and DMARC.

Fix:

Ask people who are waiting to check their spam folder first.
Open More, Emails and click Get started (a paid workspace, a domain you own and access to its DNS are required).
Enter your domain, keep or change the sender subdomain, then click Set up domain.
Add the records Lovable shows. Add the NS records inside your DNS zone for the subdomain host shown; do not replace your domain's nameservers at your registrar.
Wait for the status to show Verified (usually a few hours, up to 72), then send a test sign-up.

Source: Lovable: Send branded emails from your own domain

6. Base44: the 6-digit code never arrives

Base44 sends a 6-digit code that works for 10 minutes, from no-reply@base44-apps.com unless you set up your own email domain. Email verification cannot be turned off, so a person without the code cannot log in with their password.

Fix:

Ask the person to check spam or junk, wait a few minutes, add no-reply@base44-apps.com to their safe senders and check the address for typos.
They can ask for a new code from the verification screen, or sign up again with the same address.
If it still fails, remove their record from the Users list and ask them to sign up again. If several people report it at once, contact Base44 Customer Care with your app URL and the affected addresses.
To send from your own domain (Starter plan or above, with a domain connected): Dashboard, Domains, Email domain, Use Your Custom Domain. Add the 3 CNAME records Base44 shows and wait for the status to be Active (up to 48 hours).

Sources: Base44: Managing login and registration · Base44: Sending emails from a custom domain

7. The person missed the first email and cannot get another

A person who deleted the email or typed a wrong address is left with an unconfirmed account. In Lovable, signing in again does not resend the email.

Fix:

Supabase: give the app a "resend email" button that calls supabase.auth.resend with type signup and the person's address.
Lovable: the person signs up again with the same address. You can also add them yourself under More, Users, Add user, Create new user; users added this way are confirmed automatically.

Sources: Supabase JavaScript reference: resend() · Lovable: Email authentication for your app

Why you can't see it yourself

You're signed in, your customers aren't. Your own address is on the team, so Supabase's default sender accepts it. You sign up once, so you never reach an hourly limit. Your mail provider knows you. A new customer is outside every one of those.

FAQ

How many emails can Supabase send per hour? The default service sends 2 per hour. After you set up custom SMTP, Supabase starts at 30 per hour, which you can change on the Rate Limits page. Your email provider may have its own limits.

Can I turn off email confirmation? In Supabase, Confirm email is a setting, and Supabase says it is on by default for hosted projects. Lovable has an Auto-confirm email switch. Base44 does not let you turn verification off. Without confirmation, people get in without proving the address is theirs.

Fixed it? Prove a real stranger gets in

A fix that works from your own account proves nothing about a new customer. Your AI reads your code. VibeFix signs up like a stranger.

Still broken?

App broke after you published it? Our AI agent fixes it in your code, then tests your live app again so you see the result yourself. The first check is free. vibe-fixer.com

VibeFix is independent. Supabase, Lovable, Bolt and Base44 are trademarks of their owners.

Have you signed up to your own live app with an address that isn't on your team, and did the email arrive?

Originally published at vibe-fixer.com. I'm building VibeFix, an AI agent that finds what is breaking your live app, fixes it in your code and re-checks it.

Sign in with Google fails on my live site: redirect_uri_mismatch

VibeFix — Tue, 20 Oct 2026 08:01:07 +0000

It works for you. But a new person taps Sign in with Google on your live site and gets a Google error page, or lands back on your login page. Google's own error page tells them "only the app developer can fix this issue", so they leave.

The cause is almost always a setting, not code. Here's how to find which one.

Read the error Google shows

Open your live site in a private window, signed out of Google, and tap Sign in with Google. Google's error page names the problem:

400 redirect_uri_mismatch: the return address isn't on your Google client's list (fix 1).
400 origin_mismatch: your live site's address isn't on the list of allowed origins (fix 2).
403 access_denied: Google says this can mean "the app is in test mode and the developer hasn't added you as a test user" (fix 3).
No Google error, but you land back on your login page: the sign-in service sent them to the wrong address afterwards (fix 4).

Fix 1: the return address Google allows

Google only returns people to addresses on your OAuth client's Authorized redirect URIs list, and Google's docs say the address must match exactly: "the http or https scheme, case, and trailing slash ('/') must all match".

Supabase (including Bolt and most AI tools that use it): in Supabase, open Authentication → Providers → Google and copy the callback URL shown there. In Google Cloud, open your Web application client and paste it under Authorized redirect URIs. Note that this is Supabase's address, not your app's. If your Supabase project uses a custom domain, add that domain's callback too, "in addition to the Supabase project URL".
Lovable, Managed by Lovable: nothing to set. Lovable's docs say managed mode "needs no change when you connect a domain".
Lovable, your own Google credentials: when you connect a custom domain, Lovable adds its redirect URL to the list "but does not select it", and "until you do, Google sign-in fails on the new domain with a redirect URI mismatch error". Add that URL in Google Cloud, then select it in More → Cloud → Users → Auth settings → Google and save.
Firebase with a custom domain: add https://<your-domain>/__/auth/handler to the redirect URIs. Firebase's docs say "the trailing /__/auth/handler is important".

Google notes that changes "may take 5 minutes to a few hours" to take effect, so wait before testing again.

Fix 2: your live site as an allowed origin

On the same Google client, add your live address under Authorized JavaScript origins, just the address with no path (for example https://myapp.com, not https://myapp.com/login). Add both www and non-www if people use both.

Fix 3: the app is still in "Testing"

In Google Cloud's sign-in settings, the app's publishing status can be Testing or In production. In Testing, Google limits access to listed test users, with one exception from Google's docs: if the app asks only for name, email and profile, which is plain Sign in with Google, people "do not need to be in the trusted user list".

So if new people get 403 access_denied, check two things: which permissions your app asks Google for (anything beyond name, email and profile removes the exception), and the publishing status. Moving to In production with Publish app opens it to everyone. Google says apps using only the basic permissions don't need its verification review.

Fix 4: where people land after Google

After Google, your sign-in service sends people back to your app, but only to addresses on its allowed list. In Supabase, open Authentication → URL Configuration, set Site URL to your live address and add every live address under Redirect URLs. On Lovable, use Auth settings → Advanced → Redirect URLs or ask Lovable in the chat. On Firebase, add your live domain under Authentication → Settings → Authorized Domains.

Some Google Workspace accounts fail

If only some people fail, and the error mentions "Error getting user email from external provider", Supabase's docs say some Google Workspace setups need the email permission requested explicitly. Ask your builder to request openid, email and profile when starting Google sign-in.

Check that new people can really sign up

For Google sign-in itself, the 2-minute test above is the quickest check: a private window, signed out of Google, on your live site.

Still broken?

App broke after you published it? Our AI agent fixes it in your code, then tests your live app again so you see the result yourself. The first check is free. vibe-fixer.com

Lovable, Bolt, Replit, Base44, v0 and Supabase are trademarks of their owners.

Originally published at vibe-fixer.com. I'm building VibeFix, an AI agent that finds what is breaking your live app, fixes it in your code and re-checks it.

Login broken after publishing: users land back on the login page

VibeFix — Mon, 19 Oct 2026 08:00:28 +0000

Login worked in the preview. On the live site, users sign in and end up back on the login page, on a localhost address, or on an error. Or the confirmation link in the email opens the wrong site.

Why it happens

When someone signs in, your login service (usually Supabase) sends them back to your app. For safety, it only sends people to addresses on an approved list. Your preview address is on that list. Your published address often isn't, so the service falls back to its default, which is often localhost.

Confirm it

After signing in, look at the address bar. If it says localhost:3000 or your preview domain, this is the cause.
Open the confirmation email a new user receives and check where the link points.

Fix it (Supabase)

Open your Supabase project → Authentication → URL Configuration.
Set Site URL to your live address, e.g. https://myapp.com.
Under Redirect URLs, add your live address and, if you use more than one, each of them (with and without www).
If you use Google sign-in, check the Google Cloud console lists the callback URL that Supabase shows you.
Sign up with a fresh email on the live site and go through the whole flow once.

If it still fails

Some apps hard-code the preview address in the sign-in code. Ask your builder: "Find every place the code builds a redirect or callback URL and make it use the live site's address."

Sign-up is the one step every customer must pass. ## Still broken?

App broke after you published it? Our AI agent fixes it in your code, then tests your live app again so you see the result yourself. The first check is free. vibe-fixer.com

Lovable, Bolt, Replit, Base44, v0 and Supabase are trademarks of their owners.

Originally published at vibe-fixer.com. I'm building VibeFix, an AI agent that finds what is breaking your live app, fixes it in your code and re-checks it.

Confirmation email link opens localhost instead of my app

VibeFix — Sun, 18 Oct 2026 13:00:45 +0000

A new person signs up, opens the confirmation email, taps the link, and gets "This site can't be reached", a localhost address, or your preview instead of your app. Most of them stop right there. You never see it, because you're already signed in.

It's one of the most common sign-up breaks in apps built with AI tools, and the fix is usually a setting, not code.

Why it happens

Your sign-in service decides where the email link sends people. It only sends them to addresses on an approved list, and when your app doesn't name one, it uses a single default address, the Site URL.

That default often still points to a developer's computer. Supabase's own guide says to change the Site URL "from http://localhost:3000 to your production URL", and calls the setting "critical for email confirmations and password resets". Bolt's help center says "By default, Bolt projects use localhost:3000 as the Site URL. This does not work for live applications", and that if the address isn't on the approved list, "Supabase falls back to the Site URL."

So you publish, the app moves to its real address, and the email link still points to the old one.

Check it in 2 minutes

Open your live site in a private window, ideally on your phone.
Sign up with an email address you've never used on the app.
In the email, long-press the link (on a computer, hover over it) and read the address before you tap it.
If it starts with http://localhost, 127.0.0.1 or your preview address, this is the cause.

Fix it

Lovable, built-in backend (Cloud). Lovable sets the Site URL to your published lovable.app address when you publish, and adds a custom domain to the redirect URLs when you connect it. If the link is still wrong, ask Lovable in the chat to update them for your domain, or add your address under Auth settings → Advanced → Redirect URLs. An app that uses your own Supabase project gets no automatic updates, so use the Supabase steps below.

Supabase (including Bolt and most other AI tools that use it).

In your Supabase project, open Authentication, then URL Configuration.
Set Site URL to your live address, for example https://myapp.com.
Under Redirect URLs, add each live address: your custom domain with and without www, and the builder's published address if people use it.
Save, then sign up again with a fresh email and check the link.

If the setting is right and the link is still wrong, the address is written into the app's code. Paste this into your builder:

New users' confirmation emails link to localhost or the preview instead of my live site. Find every place the code sets a redirect or email redirect address for sign-up, sign-in and password reset, and make it use my live address: [your address]. Don't change anything else. Then tell me how to check it by signing up with a fresh email on the live site.

Then publish and check the link in a new sign-up email.

People who signed up while it was broken

Ask them to sign in on your live site. If the app says their email isn't confirmed, have them request a new confirmation email, or sign up again with the same address.

Still broken?

App broke after you published it? Our AI agent fixes it in your code, then tests your live app again so you see the result yourself. The first check is free. vibe-fixer.com

Lovable, Bolt, Replit, Base44, v0 and Supabase are trademarks of their owners.

Originally published at vibe-fixer.com. I'm building VibeFix, an AI agent that finds what is breaking your live app, fixes it in your code and re-checks it.

Supabase "permission denied for table" (42501) on new tables after 30 Oct 2026: the safe fix

VibeFix — Sun, 18 Oct 2026 06:19:56 +0000

Your newest Supabase table returns 42501 "permission denied for table", while every older table still works. With that message on a new table, the roles your app uses through the API have no GRANT on it. Supabase no longer gives the API access to new tables in the public schema automatically, and applies this to all existing projects from 30 October 2026. Add the GRANT and turn on row level security with policies in the same step: a GRANT with row level security off lets anyone who has your publishable (anon) key read every row, and that key is in your app's front end.

A save fails, a list won't load or sign-up breaks, and the response says code 42501, "permission denied for table".

The exact error

{
  "code": "42501",
  "message": "permission denied for table your_table",
  "hint": "Grant the required privileges to the current role with: GRANT SELECT ON public.your_table TO anon;"
}

Why it happens

Supabase announced on 28 April 2026 that new tables in the public schema are not reachable through the API until access is granted. It started rolling this out as the default for new projects on 30 May 2026, and applies it to all existing projects from 30 October 2026. Tables you already have keep their current access. Existing tables are not affected; the change applies to tables created after it.

Possible causes

A new table was created without granting access to the roles the API uses.
Access was granted to one role (for example signed-out visitors) but not the one the app uses (signed-in users), or the other way round.
It is a row-level security problem instead: Supabase also returns 42501 when row level security blocks an insert or update. Then the fix is a policy, not a grant.
A table with an auto-numbered column is missing access to its sequence.
An AI builder or script created the table and did not include the access it needs.

Why the hint is not the whole fix

The hint names the missing GRANT. It does not check row level security. Grants decide whether a role can reach a table; row level security decides which rows. If row level security is off and you run grant select ... to anon, every row can be read with the publishable (anon) key, and that key ships in your app's front end.

Supabase's advice is to treat three steps as one unit: grant the privileges, enable row level security, add the policies you need.

Fix steps

Run this SQL on your project's database. Replace your_table and user_id with your table and its owner column.

-- 1. Give the API roles access to the table
grant select, insert, update, delete on public.your_table to authenticated;
grant select, insert, update, delete on public.your_table to service_role;
-- Only if signed-out visitors really need to read it:
-- grant select on public.your_table to anon;

-- 2. Turn on row level security
alter table public.your_table enable row level security;

-- 3. Let each signed-in user see and change only their own rows
create policy "own rows: read" on public.your_table
  for select to authenticated using ((select auth.uid()) = user_id);
create policy "own rows: insert" on public.your_table
  for insert to authenticated with check ((select auth.uid()) = user_id);
create policy "own rows: update" on public.your_table
  for update to authenticated using ((select auth.uid()) = user_id)
  with check ((select auth.uid()) = user_id);
create policy "own rows: delete" on public.your_table
  for delete to authenticated using ((select auth.uid()) = user_id);

If the table has an auto-numbered id, grant its sequence too:

grant usage, select on all sequences in schema public to authenticated, service_role;

If you use migrations, put these statements in the same migration that creates the table, so the next new table does not break the same way.

Check which roles can reach the table

select grantee, privilege_type
from information_schema.role_table_grants
where table_schema = 'public' and table_name = 'your_table';

Check that row level security is on for every public table:

select relname as table_name, relrowsecurity as rls_on
from pg_class
where relnamespace = 'public'::regnamespace and relkind = 'r'
order by 2, 1;

Any row with rls_on = false is a table to fix before you add grants to it.

Check that the data is hidden while signed out

Run this on a table that has rows in it, using only the publishable (anon) key, the same one your app's front end uses. No sign-in token.

curl "https://YOUR-PROJECT.supabase.co/rest/v1/your_table?select=*&limit=5" \
  -H "apikey: YOUR_PUBLISHABLE_KEY"

[] (empty list) on a table that has rows: signed-out visitors see nothing. This is what you want for private data.
Rows come back: anyone with the public key can read them. If that is not intended, check rls_on with the query above and the table's policies before anything else.
42501 permission denied: signed-out visitors have no grant on this table. Fine if they should not read it.

Then sign in as one test user in your app and confirm you see your own rows and not another user's.

Why it can look fine at first

Tables you made earlier keep their access, so the pages you use most keep working. A table added after the change, for example one your AI tool just created, fails until it gets its grant.

Still broken?

If the error is gone but your live app still breaks for new users, start with a free check: Check my app free. Our AI agent signs up like a new user and shows you, with a screenshot, whether your app breaks for them. If you want it fixed, it fixes it in your code and tests your live app again.

VibeFix is independent. Supabase is a trademark of its owner.

When did you last request your newest table signed out, with only the public key?

Originally published at vibe-fixer.com. I'm building VibeFix: our AI agent fixes what breaks in your live app in your code, then tests your live app again so you see the result yourself.