Open in Terminal

functional

Drop into psql, mysql, sqlcmd, redis-cli and friends with the connection already filled in.

Right-click a server in the Object Explorer and choose Open in Terminal, or run Open Connection in Terminal from the command palette to use the active connection. SQLly opens a new terminal window running the engine's own command-line client, already connected: host, port, database, user, and TLS mode are filled in from the connection profile.

Engine	Client	How the password is passed
PostgreSQL and compatibles	`psql`	`PGPASSWORD` environment variable. The TLS mode goes in `PGSSLMODE`, and the profile's CA file, client certificate, and key in `PGSSLROOTCERT`, `PGSSLCERT`, and `PGSSLKEY`. A verifying profile without a CA file uses `PGSSLROOTCERT=system`, the system trust store (psql 16 or newer).
MySQL / MariaDB	`mysql`	`MYSQL_PWD` environment variable. The CA file and client certificate go in `--ssl-ca`, `--ssl-cert`, and `--ssl-key`. The MySQL client can only verify a certificate against a CA file, so a verifying profile without one uses the system CA bundle; if there is none (Windows), the session is encrypted but unverified and SQLly says so.
SQL Server	`sqlcmd`	`SQLCMDPASSWORD` environment variable. Integrated auth uses `-E`. SQLly reads the installed sqlcmd's `-?` banner to tell go-sqlcmd from Microsoft's ODBC sqlcmd and spells encryption the way that version accepts it: `-Nm` (mandatory, plus `-C` to trust the server certificate) or `-No` (optional, for an unencrypted profile, since sqlcmd 18 otherwise insists on encryption) for go-sqlcmd 1.4 or newer and ODBC sqlcmd 18 or newer; `-Ntrue` / `-Nfalse` for older go-sqlcmd; and a bare `-N` for ODBC sqlcmd 17 or older, which is unencrypted by default.
Redis	`redis-cli`	`REDISCLI_AUTH` environment variable. Unix-socket profiles use `-s`. The CA file and client certificate go in `--cacert`, `--cert`, and `--key`.
ClickHouse	`clickhouse-client`	`CLICKHOUSE_PASSWORD` environment variable. `clickhouse-client` speaks ClickHouse's native protocol, not the HTTP protocol SQLly uses, so it uses the connection's Native port (a ClickHouse-only field in the connection editor) when one is set. Otherwise the profile's HTTP port is mapped to the native one: 8123 to 9000 and 8443 to 9440; for any other port SQLly assumes 9000 (9440 with TLS) and says so after the launch. A custom CA or client certificate has to be set in clickhouse-client's own config file.
DuckDB / SQLite	`duckdb` / `sqlite3`	No password needed. The database file is opened directly.
Oracle	`sqlplus`, or SQLcl if SQL*Plus isn't installed	Neither client reads a password from the environment, so it prompts for the password in the terminal.

SQLly

Open in Terminal: psql running in a new terminal window, connected with the profile's settings.

Passwords never go on the command line

Anything on a command line can be seen by other users through ps, so the arguments SQLly builds never contain a secret. The password travels only in the client process's environment. On Linux and Windows the terminal inherits that environment directly, so the password is never written to disk. Terminal.app on macOS doesn't inherit the environment, so SQLly writes a short launcher script instead. The script is readable only by you, in a folder only you can open. Its first line deletes it, and it then starts the client. If Terminal never runs it, SQLly deletes it after five minutes.

Host, user, and database names are never read as shell commands, whatever characters they contain: Linux passes them to the client as separate arguments, macOS quotes them for the shell, and Windows writes them into a small launcher script with every command-prompt special character escaped. The Windows script holds no password.

Cloud IAM sign-ins (AWS RDS and Google Cloud SQL) mint their token when SQLly connects, and the token isn't handed to the terminal, so the client asks for a password; paste a fresh token there.

SSH tunnels and relays

SSH-tunneled connections connect through the tunnel's local port. Because the client then dials 127.0.0.1, a certificate check against the server's name needs help: psql dials the tunnel through PGHOSTADDR while still verifying the real host name, and redis-cli sends the real name as SNI. sqlcmd gets -F with the real host name (the host name expected in the certificate) when the installed version has that switch (go-sqlcmd 1.9 or newer, ODBC sqlcmd 18 or newer). The mysql client checks the certificate chain only (MariaDB's client connects encrypted without checking), and an older sqlcmd may refuse the certificate; SQLly notes these after the launch. For ClickHouse, whose tunnel carries the HTTP port SQLly uses, Open in Terminal opens a second forward through the same SSH hops (or proxy) to the native port (the connection's Native port, or 9000 / 9440) and points clickhouse-client at it. That forward stays open until you disconnect the connection or quit SQLly; disconnecting closes it and ends the terminal session. Through the tunnel clickhouse-client checks a verified certificate against 127.0.0.1, so SQLly notes that it may be refused. A Kubernetes port-forward carries only the connection's own port, so ClickHouse over Kubernetes can't open a terminal. Connections that go through a relay bridge can't open a terminal at all: the client would have to reach the database directly from this machine.

macOS: the password briefly touches disk. This is the one place SQLly writes a saved password to a file, so the first time you open a terminal for a connection with a saved password, SQLly explains it before anything is written. Choose Open Terminal to go ahead or Cancel to stop. Tick Don't show this again to skip the note from then on, and turn it back on in Settings › Advanced › Database tools. To keep the password off disk entirely, remove it from the connection profile and the client will ask for it in the terminal. Linux and Windows never write it to disk, so they don't show the note.

The macOS Open in Terminal notice explaining the self-deleting launcher script, with a Don't show this again checkbox.

Which terminal opens

macOS: Terminal.app, opened through Launch Services. No Automation permission prompt.
Linux: $TERMINAL if you set it, then x-terminal-emulator, GNOME Terminal, Konsole, Xfce Terminal, kitty, Alacritty, WezTerm, and xterm. SQLly uses the first one it can start. A $TERMINAL naming one of those gets that terminal's own way of running a command. The window stays open after the client exits so you can read any error; press Enter to close it.
Windows: a new console window that stays open after the client exits; press any key to close it.

SQLly finds the clients the same way it finds the dump tools. Path overrides set in Preferences apply here too. If a client isn't installed, the menu item is disabled and says what to install. It is also disabled, with the reason, for connections a terminal client can't take over: in-memory DuckDB and SQLite, libSQL/Turso over HTTP, Entra sign-in on SQL Server, and relay connections. DuckDB lets only one program use a file at a time, so while SQLly has a DuckDB file open, Open in Terminal asks you to disconnect first. A profile whose password is still in the keyring is resolved first. If there is no password, the client prompts for one. The browser version can't open terminals.