Steps to Reproduce

1. Create a .env file with the following content (invalid password):

  % cat .env
SUPABASE_DB_PASSWORD=xxxx

2. Run the following command (valid password):

  % supabase link --project-ref ojjfemmmplnpzwdxwcwb --password password

3. Observe that the --password argument is ignored, and the value from .env is used instead.

Expected Behavior

The .env file should not be used in this case. If it is considered, the --password argument should take precedence over .env.

Actual Behavior

The value from .env is used instead of the --password argument.

Additional Information

The following case works correctly:

  % SUPABASE_DB_PASSWORD=password supabase link --project-ref ojjfemmmplnpzwdxwcwb

This suggests that the current priority order is Environment Variable > .env > Command-Line Argument.

Additionally, it appears that other Supabase CLI commands also rely on the password stored in .env. As a result, if supabase link is executed using an environment variable like:

% SUPABASE_DB_PASSWORD=password supabase link --project-ref ojjfemmmplnpzwdxwcwb

then subsequent commands may require either setting the password via environment variables or writing it to .env. Given that link modifies the environment in a breaking way, it would be preferable for the password to be included as part of the new linked environment. Otherwise, users who manage multiple remotes would need to manually switch .env or environment variables each time they run supabase link, which can be cumbersome.

Environment

• Supabase CLI version: 2.19.5
• OS: Ubuntu22(WSL2)