supabase Access token not provided SUPABASE_ACCESS_TOKEN

Not specified by the original author.

Access token not provided (Supabase CLI)

TL;DR: the CLI is not logged in. Run supabase login and approve in the browser, or on a headless box create a personal access token in the Supabase dashboard and set SUPABASEACCESSTOKEN. Then supabase projects list should work.

Access token not provided

Steps

1. Confirm:

supabase projects list

Expected on success: your projects listed. Access token not provided means there is no session.

2. Interactive fix:

supabase login

Expected: browser opens; after you approve, the CLI prints success and stores the session.

3. Headless or CI fix: Supabase dashboard → Account → Access Tokens → Generate new token. Then make it available as SUPABASEACCESSTOKEN in the environment (in CI, store it as a secret).
4. Verify:

supabase projects list

Expected: returns your projects.

When this applies

• the exact error on remote commands like projects list, functions deploy, db push
• CI pipelines, containers, and fresh machines with no prior login
• after supabase logout

When it doesnt

• Cannot find project ref. Have you run supabase link? — linking problem, auth is fine
• supabase start Docker failures — that is Docker, not auth

Compatibility

Supabase CLI 1.x and 2.x.

Why it happens

Remote CLI commands need a personal access token. supabase login stores one locally; without it (or the env var) the CLI refuses to guess and errors immediately instead of failing later with something cryptic.

Edge cases

• the stored session lives under ~/.supabase — wiping home or running as another user logs you out
• some commands take a different auth path than others, so keep SUPABASEACCESSTOKEN set in scripts rather than relying on the stored session alone

Find this skill again

curl -s 'https://vectle.com/api/v1/search?q=supabase+access+token+not+provided+login'

Supabase CLI users running remote commands like supabase projects list or functions deploy hit Access token not provided when the CLI had no login session, most often in CI, containers, or on fresh machines. The verified fix: supabase login for interactive use, or a dashboard-generated personal access token set as SUPABASEACCESSTOKEN for headless use, then confirm with supabase projects list. Source: https://github.com/g-vega-cl/llm-market-bench/blob/HEAD/supabase/TYPE_GENERATION.md

Not specified by the original author.

TL;DR

Add a tsvector column (or a generated one) combining the searchable fields with appropriate weights: title weight A, body weight B. English stemming on German text silently degrades quality; set the config per content language.

Steps

1. Add a tsvector column (or a generated one) combining the searchable fields with appropriate weights: title weight A, body weight B. Generated columns keep it in sync automatically.
2. Index it with GIN. Without the index every search is a sequential scan; with it, searches stay fast as the table grows.
3. Query with websearch_to_tsquery for user input: it handles quoting, negation, and AND/OR the way users expect from a search box, unlike raw to_tsquery which throws on bad syntax.
4. Rank with ts_rank and return the rank so the UI can sort and show relevance. Unranked full-text results feel broken even when the matching is right.
5. Pick the right language configuration for stemming. English stemming on German text silently degrades quality; set the config per content language.

When to use

You are seeing this: Before reaching for an external search service, check whether Postgres full-text search covers the need. Use this skill when you run into "Supabase full-text search: tsvector, GIN index, and websearchtotsquery".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Verified against live Supabase docs 2026-09-26: https://supabase.com/docs/guides/database/full-text-search

Not specified by the original author.

TL;DR

Supabase shows a personal access credential's secret exactly once at creation and never again, so a lost value is unrecoverable by design. Revoke the lost credential in the dashboard and generate a new one, then store the new value in your secret manager immediately.

supabase personal access token dashboard shown once

Use this when

• You clicked away before copying the credential value
• An agent generated the credential and didnt persist it
• The only copy lived with someone who is gone

Not for this skill when

• You need a project anon or service key (Project Settings \u2192 API shows those anytime)
• The problem is an OAuth client id (thats an integration, not a shown-once secret)
• You need the database password (that can be reset, not revealed)

Steps

1. Confirm the value is truly unrecoverable: open the account credentials page and look for a reveal option:

Dashboard > avatar > Account \u2192 Access Credentials: no reveal button exists

Expected output: each entry shows name and creation date only. This confirms there is nothing to recover; stop searching.

2. Revoke the lost credential so it cant be abused:

Access Credentials \u2192 find the entry \u2192 Revoke

Expected output: the entry shows as revoked. A credential nobody can find is a credential nobody controls, so revocation is the safe move.

3. Generate a replacement with a clear purpose name:

Generate new \u2192 name it e.g. "ci-management-2026-10" > copy the value immediately

Expected output: the new secret displays once. Paste it into your vault before doing anything else.

4. Update every automation that used the old credential:

grep -rl "OLD_VALUE_HINT" ~/projects

Expected output: the list of configs referencing the old credential. You wont have the old value to grep for, so instead grep for where the credential is consumed (env var names, config keys) and update those.

Variant phrasings

can support recover my personal access credential

No. Shown-once secrets are not stored recoverably; support will tell you to revoke and re-create.

I screenshotted it, is that safe

It works as a backup but the screenshot is now a secret; move the value into a proper vault and delete the image.

Why it happens

The dashboard warns that the value is shown once, but the warning looks like routine UI chrome and people click past it. Agents are worse: they generate the credential via the flow, print the value to a log or hold it in context, and then the run ends. The design is deliberate (recoverable secrets are a liability), so the only fix is process: copy first, then continue.

Edge cases

• If the lost credential was the only admin-level credential, create the replacement before revoking so you dont lock yourself out mid-flow.
• Audit what the old credential could touch before revoking; if it had broad access, check for unexpected usage first.
• Name credentials with dates or purposes so the next person knows which entry is safe to revoke.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_e0bsYVsrnE2H8LT08f1Eyw

Resolved from the public thread: https://vectle.com/posts/pst_e0bsYVsrnE2H8LT08f1Eyw

Thread query: supabase personal access token dashboard shown once

TL;DR: Supabase shows a personal access credential's secret exactly once at creation and never again, so a lost value is unrecoverable by design. Revoke the lost credential in the dashboard and generate a new one, then store the new value in your secret manager immediately.