CLI migration list fails with 42501 while initializing cli_login_postgres

[cHmirandaalos]

Summary

supabase migration list --linked fails before returning migration metadata
because the CLI attempts to initialize the managed cli_login_postgres role
and receives PostgreSQL error 42501.

Environment

• Windows PowerShell
• Supabase CLI 2.67.1 and 2.116.0
• Hosted Supabase project
• Authentication and project linkage verified

Sanitized behavior

The CLI reports that it is initializing its login role and then fails because
the managed operation is not authorized to alter cli_login_postgres.

No remote mutation succeeded, and no migration metadata was returned.

Read-only diagnostics

The role exists, and membership checks returned:

• postgres_is_member_of_cli_login_postgres = false
• cli_login_postgres_is_member_of_postgres = true

This appears to rule out the previously documented reversed/circular
membership condition.

Question

Has anyone encountered this project-side managed-role permission state?

Is there a supported customer action, or must Supabase repair the internal
ADMIN OPTION/role-management relationship?

I am specifically avoiding:

• DROP ROLE
• ALTER ROLE
• GRANT or REVOKE
• DROP OWNED or REASSIGN OWNED
• granting CREATEROLE
• database password workarounds

A Supabase Support case is already open. I am looking for confirmation of the
supported remediation, not an unsupported role modification.

Security

Raw CLI output is intentionally omitted because it contained transient
credential material. No passwords, tokens, connection strings, customer data,
project reference, or raw logs are included.

[Bushra-KB]

This is a known internal role-management state that the CLI can't self-repair. The cli_login_postgres role exists, but the postgres superuser no longer holds ADMIN OPTION over it, so the CLI's initialization step (which tries to alter/grant on that role) is rejected with 42501.

There is no supported customer-side action here — you're right to avoid all the DDL workarounds. This must be fixed on Supabase's infrastructure side by restoring the correct ADMIN OPTION grant to the postgres role. Your support case is the correct path; the team has access to the internal tooling needed to repair the managed-role relationship.

If you want to unblock yourself in the meantime, supabase db remote commit (which bypasses the login-role init step in some CLI versions) may work, but that depends on your CLI version and project state.