Connecting to Snowflake from the Command Line: Snowflake CLI and SnowSQL in 2026

Last updated: October 2026

Introduction

This guide was first written for SnowSQL in 2024, and two things have changed since. Snowflake now treats SnowSQL as a legacy client and puts new command-line features only into Snowflake CLI. And Snowflake's multi-factor authentication rollout, whose final phase ran from August to October 2026, means the password-only login that most SnowSQL tutorials show no longer works. This version covers both tools, how to sign in today, and how to load a local file into a table.

SnowSQL or Snowflake CLI?

Snowflake describes SnowSQL as a legacy command-line client and Snowflake CLI as the preferred client for new installations and new work. SnowSQL is still supported, but each minor version has an end date:

• SnowSQL 1.5.x: released 16 April 2026, supported until 16 April 2028.
• SnowSQL 1.4.x: supported until 22 May 2027.
• SnowSQL 1.3.x: support ended on 2 May 2026.

If you already have scripts built on SnowSQL, keep them on 1.5.x and plan to move them. For anything new, start with Snowflake CLI, which also manages stages, apps, notebooks and other objects.

Signing in after the 2026 MFA changes

Snowflake's third MFA phase, rolled out between August and October 2026, changed what each kind of user can do:

• People (users of TYPE PERSON) need a second factor for any password sign-in, with no exceptions. In practice, use single sign-on through your identity provider, or a password with an MFA passcode.
• Service users (TYPE SERVICE) cannot use passwords at all. Scripts and tools sign in with key-pair authentication or OAuth.
• Legacy service users (TYPE LEGACY_SERVICE) are blocked from passwords and are being migrated to SERVICE, and new ones cannot be created.

Setting up Snowflake CLI

Snowflake CLI is available as installers for macOS, Windows and Linux (deb and rpm), through Homebrew, or as a Python tool, which needs Python 3.10 or later. With pipx, which keeps it out of your other Python environments, the install is one command:

pipx install snowflake-cli
snow --help

Connections live in config.toml, or in a connections.toml file in the same directory. On macOS and Linux the directory is ~/.snowflake/, and the file must be readable only by its owner (chmod 0600). Two connections cover most needs: single sign-on for yourself, and key-pair authentication for a script.

[connections.me]
account = "myorg-myaccount"
user = "jdoe"
authenticator = "EXTERNALBROWSER"     # opens your identity provider in a browser
warehouse = "DEV_WH"
role = "ANALYST"

[connections.loader]
account = "myorg-myaccount"
user = "SVC_LOADER"
authenticator = "SNOWFLAKE_JWT"       # key-pair authentication
private_key_file = "~/.snowflake/keys/svc_loader.p8"
warehouse = "LOAD_WH"
role = "LOADER"

You can also create a connection interactively with snow connection add. Then test it and, if you like, make it the default:

snow connection test -c me
snow connection set-default me
snow sql -q "SELECT CURRENT_USER(), CURRENT_ROLE(), CURRENT_WAREHOUSE();"

The EXTERNALBROWSER authenticator only works in a terminal that can open a web browser, so use key-pair authentication for jobs on servers.

Connecting with SnowSQL

SnowSQL reads named connections from ~/.snowsql/config (%USERPROFILE%\.snowsql\config on Windows). Passwords stored there are kept in plain text, which is one more reason to use single sign-on or a key pair instead.

[connections.me]
accountname = myorg-myaccount
username = jdoe
authenticator = externalbrowser
warehousename = DEV_WH
rolename = ANALYST

# Connect with the named connection
snowsql -c me

# A password sign-in now needs a second factor
snowsql -a myorg-myaccount -u jdoe --mfa-passcode 123456

# A service user signs in with its private key
snowsql -a myorg-myaccount -u SVC_LOADER --private-key-path ~/.snowflake/keys/svc_loader.p8

Creating a service user for scripts

A script should run as a SERVICE user with a key pair, not as a person. Generate the key pair with OpenSSL, register the public key on the user, and keep the private key in a secrets store or a file only the job can read.

openssl genrsa 2048 | openssl pkcs8 -topk8 -inform PEM -out svc_loader.p8 -nocrypt
openssl rsa -in svc_loader.p8 -pubout -out svc_loader.pub

CREATE ROLE IF NOT EXISTS loader;
GRANT USAGE ON WAREHOUSE load_wh TO ROLE loader;
GRANT USAGE ON DATABASE demo_db TO ROLE loader;
GRANT USAGE, CREATE TABLE, CREATE STAGE ON SCHEMA demo_db.public TO ROLE loader;

CREATE USER IF NOT EXISTS svc_loader
  TYPE = SERVICE
  RSA_PUBLIC_KEY = '<contents of svc_loader.pub without the BEGIN/END lines>'
  DEFAULT_ROLE = loader
  DEFAULT_WAREHOUSE = load_wh;

GRANT ROLE loader TO USER svc_loader;

Loading a local file into a table

Loading a file from your machine takes three steps: create a table and an internal stage, upload the file to the stage, and copy it into the table. The SQL is the same whichever client you use; only the upload step differs.

CREATE DATABASE IF NOT EXISTS demo_db;
USE SCHEMA demo_db.public;

CREATE OR REPLACE TABLE employees (
    employee_id INTEGER,
    full_name   VARCHAR,
    department  VARCHAR,
    hired_on    DATE
);

CREATE OR REPLACE STAGE employees_stage
  FILE_FORMAT = (TYPE = CSV SKIP_HEADER = 1 FIELD_OPTIONALLY_ENCLOSED_BY = '"');

# Snowflake CLI
snow stage copy ./employees.csv @demo_db.public.employees_stage

# SnowSQL (inside a session)
PUT file:///home/jdoe/data/employees.csv @employees_stage AUTO_COMPRESS = TRUE;

COPY INTO employees
  FROM @employees_stage
  ON_ERROR = ABORT_STATEMENT;

SELECT COUNT(*) AS rows_loaded FROM employees;
SELECT * FROM employees LIMIT 10;

COPY INTO records which files it has loaded, so running it again does not load the same file twice. To reload a file deliberately, add FORCE = TRUE.

Other everyday commands

Once connected, the usual administration commands work in either client:

SHOW ROLES;
SHOW DATABASES;

CREATE ROLE IF NOT EXISTS reporting;
GRANT USAGE ON DATABASE demo_db TO ROLE reporting;
CREATE SCHEMA IF NOT EXISTS demo_db.reporting;

CREATE WAREHOUSE IF NOT EXISTS reporting_wh
  WAREHOUSE_SIZE = 'XSMALL'
  AUTO_SUSPEND = 60
  AUTO_RESUME = TRUE;
SHOW WAREHOUSES LIKE 'REPORTING_WH';

One detail on the last statement: since Snowflake's 2026 behavior change bundles, a standard warehouse created without a GENERATION setting is Gen2 where available, which bills 1.35 credits an hour at X-Small on AWS and Google Cloud and 1.25 on Azure, and query acceleration is switched on by default. Add GENERATION = '1' or ENABLE_QUERY_ACCELERATION = FALSE if you want the older behaviour.

Conclusion

For new work, use Snowflake CLI with single sign-on for people and key-pair authentication for scripts, and keep SnowSQL only where existing jobs depend on it. Either way, the password-only login of older tutorials no longer works after Snowflake's 2026 MFA changes. To take your transformations further, see how dbt works with Snowflake for ELT.

Frequently Asked Questions