DEV Community: VibeFix

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.

Check that new people can really sign up

Paste your app's link at vibe-fixer.com for a free sign-up check. An AI agent signs up to your live app as a brand-new person, with a real inbox, on a phone and a computer, and shows whether a new person can finish. Every app gets one free check, no card. It checks your app; it never changes it.

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 signs up to your live app like a brand-new person and shows what breaks.

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

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

Published 17 Oct 2026 · Last checked: 17 Oct 2026 against Supabase's changelog and docs.

From 30 October 2026, a new table you create in the public schema of an existing Supabase project is no longer reachable through the API until you grant access to it. The error you see is 42501 permission denied for table. Fix: run a GRANT for that table in the SQL Editor (statements below), and keep RLS on.

If your error says new row violates row-level security policy, that is a different problem. The grant is fine and a policy is blocking the row. See Data won't save? Row level security.

The same rule has applied since 30 May 2026 to projects created from that date, as a gradual rollout, and to any project where "Automatically expose new tables" was unticked at creation. If your project is newer than that, you may already see this error. On 30 October 2026 it reaches all existing projects.

What changed on 30 October 2026

Supabase announced a breaking change: new tables in the public schema need an explicit Postgres grant before the Data API can see them. The Data API is the layer your app calls when it uses supabase-js or sends requests to /rest/v1/ or /graphql/v1. Supabase applies this to all existing projects on 30 October 2026. (Supabase changelog)

New table in public: before, default projects gave anon, authenticated and service_role select, insert, update and delete. From 30 Oct 2026, you must grant access yourself.
Tables you already have: still reachable. They keep their current grants.
Direct Postgres connection (psql, an ORM, a connection string): not part of the Data API, so not affected.

Who is affected: apps that reach the database through the Data API. Supabase names these triggers: migrations or setup scripts that create public tables without a GRANT, and an AI coding tool, CLI script or Management API call that creates tables and expects API access.

If your builder creates tables in a Supabase project you own, and the project already exists on 30 Oct, the rule above applies to tables created after that date. Your old tables keep working.

What the error looks like

When a grant is missing, the API answers with a clear error, not a silent failure. It looks like this:

{"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;"}

The hint names the role and the privilege that are missing. Your app may show this as a failed save, an empty list or a broken sign-up. The HTTP status can be 401 or 403 with the same code 42501. (Supabase: Securing your API, Supabase: 42501 errors)

Missing grant or RLS policy? How to tell

Both errors carry code 42501. Read the message.

Missing grant: the message is permission denied for table your_table, with a hint that gives the GRANT to run. The role cannot reach the table at all, so any read or write fails. Fix: the grant in the next section.
RLS blocking the row: the message is new row violates row-level security policy for table "your_table", and the example in a Supabase GitHub discussion shows no hint. The role can reach the table, but a policy rejects this row, typically on INSERT or UPDATE. Fix: add or correct a policy (see this guide).

Grants and RLS are two separate layers. Grants decide whether a role can reach the table. RLS decides which rows. If the grant is missing, Postgres rejects the query before RLS comes into play. Supabase also says that anon or authenticated doing an INSERT or UPDATE without the needed RLS permission returns a 42501 error. (Supabase: 42501 errors) The RLS message text above comes from a Supabase GitHub discussion, not from the documentation.

The fix: grant, enable RLS, add a policy

Don't want to type the table name by hand? Make the SQL for your table: type the name, tick the roles, copy the SQL.

Supabase says to treat these three steps as a unit. This is the SQL from their changelog. Replace your_table with your table name. Use the table name and role shown in your own error hint. (Supabase changelog, "What to do")

Grant the privileges the role needs:
- grant select on public.your_table to anon;
- grant select, insert, update, delete on public.your_table to authenticated;
- grant select, insert, update, delete on public.your_table to service_role;
Enable RLS:
- alter table public.your_table enable row level security;
Add the policies you need, for example:
- create policy "users can read their own rows" on public.your_table for select to authenticated using (auth.uid() = user_id);

Notes:

Keep the anon line only if signed-out visitors should be able to read the table. Supabase says to grant the minimum privileges each role needs. (Securing your API)
Supabase's docs also show single-role forms, such as grant select on table public.your_table to anon;. (42501 errors)
Do not copy a bulk "grant on all tables" statement as your fix. It would open every table, including private ones. Supabase publishes one only as a rollback option, in the FAQ of the changelog.
If your table has an auto-numbered column, Supabase says new sequences also need explicit grants. The changelog's rollback block shows the grant usage, select form for sequences. Read it before you copy it.
The policy in step 3 is an example. Write the policy your app needs. See Users can see other users' data.

Where to run it

Open your project in the Supabase dashboard.
Open the SQL Editor (direct link: https://supabase.com/dashboard/project/_/sql/new).
Paste the statements, change the names, and run them.

Supabase also says you can change table privileges in Integrations > Data API in the dashboard, or with SQL. (42501 errors) Check the menu labels on your own screen, as the dashboard can change.

Check what you already have

To see which roles have access to a table, run this in the SQL Editor:

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

(Supabase: 42501 errors)

Supabase also says the Data API exposure badge in the Table Editor and the Security Advisor list the tables worth reviewing. Look in your dashboard for them. (Supabase changelog)

If an AI builder creates your tables

Any tool that creates tables in your Supabase project, an AI builder included, has to include the grants for new tables. If you ask your builder to add a table, say so in the prompt. Here is a sentence you can paste:

"When you create a new table in the public schema, also write the GRANT statements for the roles that need it, enable row level security, and add the policies. Show me the SQL before you run it."

This page does not say which builder does or does not add grants for you. Check the SQL your builder produced.

Things that do not change

Tables you already have keep their grants and stay reachable.
Apps that talk to the database only over a direct Postgres connection are not affected.

How to confirm the fix on your live app

Open your live app in a private window, so you are signed out.
Sign up with a fresh email, like a new person.
Do the thing that was failing: save the row, load the list.
If it works, the grant is in place. If it still fails, read the message again with the comparison above.

If sign-up itself still fails, the cause may be email, not permissions. See Confirmation emails not arriving and Login broken after publish. For a full walk-through, see Test your live app like a real customer.

VibeFix's check covers the sign-up part of this: its AI agent signs up to your live app like a new person and shows whether sign-up and your pages work. It does not look inside your Supabase project or read your grants. VibeFix checks; it does not fix your app.

FAQ

Do I need to change anything for tables I already have? No. Existing tables keep their current grants and stay reachable.

Does this affect me if my app only uses a direct database connection? No. The change applies to the Data API.

Is 42501 always a grant problem? No. The same code is used when row level security blocks an INSERT or UPDATE. Read the message text.

Do I still need RLS after granting? Yes. A grant does not replace RLS. Treat grant, enable RLS and policy as one unit.

Can I get ahead of the change now? Supabase documents how to opt in early in the "Opting in on existing projects" section of its changelog. This is for advanced users: read their rollback notes first.

Sources

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

Originally published at vibe-fixer.com.