supabase link / supabase projects api-keys fail with "insufficient privileges" while the identical token succeeds via direct API call
Bug report
supabase link (and supabase projects api-keys) fail with an "insufficient privileges" error, while the exact same personal access token, hitting the equivalent Management API endpoint, succeeds via a plain curl call.
Environment
- CLI version:
2.116.0 (also reproduced on 2.107.0 before upgrading)
- OS: macOS (Darwin 25.6.0)
- Install method: Homebrew
- Org plan: Pro, Owner role, billing/payment method on file
Steps to reproduce
supabase link --project-ref <ref>
Output:
{"_tag":"Error","error":{"code":"LegacyLinkProjectStatusError","message":"Unexpected error retrieving remote project status: {\"message\":\"Your account does not have the necessary privileges to access this endpoint. For more details, refer to our documentation https://supabase.com/docs/guides/platform/access-control\"}"}}supabase projects api-keys --project-ref <ref> fails the same way.
Proof the token itself is fine
Using the same SUPABASE_ACCESS_TOKEN the CLI is resolving (verified via env var, not --profile, see below), a direct call to the Management API succeeds:
curl -s -o /dev/null -w "%{http_code}\n" -X GET \
"https://api.supabase.com/v1/projects/<ref>" \
-H "Authorization: Bearer $SUPABASE_ACCESS_TOKEN"
# => 200
Same token, same project, same account — CLI rejects it, raw REST call accepts it.
What we ruled out
- Token scope — token has full scope, confirmed via the dashboard.
- Org role — Owner.
- Billing — payment method on file, no past-due invoices.
- Plan tier — Pro.
- CLI version — reproduced on both 2.107.0 and the latest 2.116.0 at time of filing.
- Local CLI state/cache — deleted
~/.supabase/profile and other local CLI state, re-authenticated from scratch, still reproduces.
--profile isolation — also found that --profile doesn't appear to isolate credentials as expected (logging a token under an unrelated profile name still authenticated as the real account), so we're resolving the token via SUPABASE_ACCESS_TOKEN env var instead, not --profile. Not certain this is related to the 403, flagging in case it's the same root cause (e.g. profile/account resolution picking the wrong context internally before the privilege check).
Impact
Can't use supabase link / supabase db push / supabase projects api-keys at all against this project. Working around it by scripting equivalent calls directly against the Management API (POST /v1/projects/{ref}/database/query), which work fine and confirms the backend/account itself has no permission issue — this looks CLI-internal.
supabase link/supabase projects api-keysfail with "insufficient privileges" while the identical token succeeds via direct API callBug report
supabase link(andsupabase projects api-keys) fail with an "insufficient privileges" error, while the exact same personal access token, hitting the equivalent Management API endpoint, succeeds via a plaincurlcall.Environment
2.116.0(also reproduced on2.107.0before upgrading)Steps to reproduce
Output:
{"_tag":"Error","error":{"code":"LegacyLinkProjectStatusError","message":"Unexpected error retrieving remote project status: {\"message\":\"Your account does not have the necessary privileges to access this endpoint. For more details, refer to our documentation https://supabase.com/docs/guides/platform/access-control\"}"}}supabase projects api-keys --project-ref <ref>fails the same way.Proof the token itself is fine
Using the same
SUPABASE_ACCESS_TOKENthe CLI is resolving (verified via env var, not--profile, see below), a direct call to the Management API succeeds:Same token, same project, same account — CLI rejects it, raw REST call accepts it.
What we ruled out
~/.supabase/profileand other local CLI state, re-authenticated from scratch, still reproduces.--profileisolation — also found that--profiledoesn't appear to isolate credentials as expected (logging a token under an unrelated profile name still authenticated as the real account), so we're resolving the token viaSUPABASE_ACCESS_TOKENenv var instead, not--profile. Not certain this is related to the 403, flagging in case it's the same root cause (e.g. profile/account resolution picking the wrong context internally before the privilege check).Impact
Can't use
supabase link/supabase db push/supabase projects api-keysat all against this project. Working around it by scripting equivalent calls directly against the Management API (POST /v1/projects/{ref}/database/query), which work fine and confirms the backend/account itself has no permission issue — this looks CLI-internal.