Cannot connect to cloud-sql-proxy with passwordless login

[ptwales]

I'm running cloud-sql-proxy with --auto-iam-authn to connect to a google hosted sql database. I cannot connect to that database proxy with mycli>=1.43.0. Older versions of mycli work (latest 1.42.0), so does usql and the stock mariadb client.

Expected Behavior

While running

cloud-sql-proxy --auto-iam-authn <PROJECT>:<ZONE>:<DB> --port 3308

I should be able to immediately connect to that database without providing a password with

mycli -h 127.0.0.1 -P 3308 -u <USER> -D <DATABASE>

Actual Behavior

I get the output

# 2026-02-18 12:12:47,988 WARNING mycli.config config.py:23 -- Unable to parse line 10 of config file '/etc/my.cnf'.

# 2026-02-18 12:12:47,988 WARNING mycli.config config.py:23 -- Using successfully parsed config values.

# 2026-02-18 12:12:47,988 WARNING mycli.config config.py:23 -- Unable to parse line 52 of config file '/etc/my.cnf.d/server.cnf'.

# 2026-02-18 12:12:47,988 WARNING mycli.config config.py:23 -- Using successfully parsed config values.

Enter password for <USER>: <CR>
# 2026-02-18 12:12:49,080 ERROR mycli.main main.py:721 -- traceback: 'Traceback (most recent call last):\n  File "/usr/lib/python3.14/site-packages/mycli/main.py", line 718, in connect\n    _connect()\n    ~~~~~~~~^^\n  File "/usr/lib/python3.14/site-packages/mycli/main.py", line 682, in _connect\n    raise e1\n  File "/usr/lib/python3.14/site-packages/mycli/main.py", line 640, in _connect\n    self.sqlexecute = SQLExecute(\n                      ~~~~~~~~~~^\n        database,\n        ^^^^^^^^^\n    ...<14 lines>...\n        unbuffered,\n        ^^^^^^^^^^^\n    )\n    ^\n  File "/usr/lib/python3.14/site-packages/mycli/sqlexecute.py", line 189, in __init__\n    self.connect()\n    ~~~~~~~~~~~~^^\n  File "/usr/lib/python3.14/site-packages/mycli/sqlexecute.py", line 280, in connect\n    conn = pymysql.connect(\n        database=db,\n    ...<15 lines>...\n        cursorclass=pymysql.cursors.SSCursor if unbuffered else pymysql.cursors.Cursor,\n    )  # type: ignore[misc]\n  File "/usr/lib/python3.14/site-packages/pymysql/connections.py", line 365, in __init__\n    self.connect()\n    ~~~~~~~~~~~~^^\n  File "/usr/lib/python3.14/site-packages/pymysql/connections.py", line 681, in connect\n    self._request_authentication()\n    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^\n  File "/usr/lib/python3.14/site-packages/pymysql/connections.py", line 958, in _request_authentication\n    auth_packet = self._read_packet()\n  File "/usr/lib/python3.14/site-packages/pymysql/connections.py", line 751, in _read_packet\n    packet_header = self._read_bytes(4)\n  File "/usr/lib/python3.14/site-packages/pymysql/connections.py", line 805, in _read_bytes\n    raise err.OperationalError(\n        CR.CR_SERVER_LOST, "Lost connection to MySQL server during query"\n    )\npymysql.err.OperationalError: (2013, \'Lost connection to MySQL server during query\')\n'

(2013, 'Lost connection to MySQL server during query')

The cloud-sql-proxy process only logs

Accepted connection from 127.0.0.1:34430
instance closed the connection

The my.cnf warnings I believe are unrelated but I'm including them in case I'm wrong.

Steps to Reproduce

You'll need a mysql database from hosted by google. I can't provide instructions for setting that up because I didn't set this one up. You'll also need to install gcloud and connect to the project with the database. Once you have all that set up its just the two commands I gave in Expected Behavior.

System

• mycli version: Anything above 1.43.0
• OS/version: Arch linux 6.12.68-1-lts
• cloud-sql-proxy version: 2.21.0+linux.amd64

Discussion

I'm currently circumventing by manually downgrading the PKGBUILD to 1.42.0. I get some warnings about "No user completions due to... (permissions error)" but I can live with that.

[rolandwalker]

Hi! Interesting!

What happens if you add --ssl-mode=off to a 1.43.0+ mycli, like

mycli --ssl-mode=off -h 127.0.0.1 -P 3308 -u <USER> -D <DATABASE>

?

(Yes, the my.cnf errors are hopefully unrelated, and we plan to stop reading those files entirely.)

[ptwales]

@rolandwalker That works with versions 1.43.0 - 1.44.2. With >=1.45.0 it will still prompt for password, but will log me in.

Adding --password="" skips the password prompt, which is good enough for me. IDK if you consider that a bug though.

[rolandwalker]

Great!

Switching to SSL by default was intentional, but you should have been provided with a more informative error message for sure!

If the password is indeed the empty string, maybe the need for --password="" isn't a bug. But we will investigate what changed.

You can set the default SSL mode to off by turning off this option in the ~/.myclirc file:

[connection]
default_ssl_mode = off

Though we would like to also have a per-host setting in the file, it isn't there yet.

[scottnemes]

@rolandwalker The password behavior is the currently expected behavior, but possible to change depending on desired functionality. The change is because prior to 1.45.0, mycli would simply attempt to connect to the DB no matter what, and then on failure would proceed to ask for a password. Where as now if after exhausting every password source there is no password given, it will prompt for a password. So in the case of an empty password, we do not know if the user simply did not give a password, or if the user account actually has no password.

Only way to handle that situation differently would be to either A) go back to attempting to connect no matter what and then ask on failure (not great, but gives the functionality), or B) have some other way of telling mycli that password should be empty, like --no-password, but at that point it's not much different than --password="".

For my local test setup, I just put password= in ~/.my.cnf, which to me makes sense to me. So my vote is leave this as-is anyway.

RE: SSL, I'll take a look at the error path for connections that cannot have SSL when auto is set; pretty sure I tested that before and it worked, but may either be something specific with the cloud-sql proxy or something else changed that no longer outputs a useful error perhaps.

[rolandwalker]

The 1.45.0 changes were good because they made connection faster, right?

We could create a non-default config option that brings back something similar to the old behavior, right?

[scottnemes]

The original goal was to speed up connections yeah, but that proved to be mostly moot as 99% of the startup time is other things that happen no matter what. So if we want to better support the empty password situation again, it might make more sense to just go back to a connect first ask questions later setup, hopefully more efficient than before but would have to see what the options are with the current logic.

EDIT: forgot that we did add support for the password prompting logic (i.e. -p), so that actually will help us here. Basically if by the end we find no password provided, and -p / --password is not provided (as a prompt, no password given) then at that point just try to connect. That would at least limit the time we attempt to connect without a password, since at that point the only case left is either the user has no password, or they forgot to provide one.

[scottnemes]

For the SSL piece, I did some basic testing and verified that the cloud-sql-proxy does seem to return a (2013, 'Lost connection to MySQL server during query') in the case of an SSL issue, which is a fairly generic error unfortunately. We could have ssl-mode=auto downgrade to cleartext on the more generic error, however that would definitely be a downgrade for security since we could be bypassing SSL for an unrelated issue.

For now I will just plan to add some extra error output for that error code for the user to try without ssl and/or to check the server ssl config, which would help the user out without enforcing worse security.