@cli4ai/snowflake

> Official @cli4ai package • https://cli4ai.com • Install cli4ai: npm i -g cli4ai

Snowflake explorer with read-only SQL (blocks writes by default).

Setup

``bash
npm i -g cli4ai
cli4ai add -g snowflake
`

Create ~/.snowflake/connections.toml (required). Example:

`toml
[dev]
account = "xy12345.us-east-1"
user = "YOUR_USER"
password = "YOUR_PASSWORD"
warehouse = "COMPUTE_WH"
role = "SYSADMIN"
database = "MY_DB"
schema = "PUBLIC"
`

Then verify:

`bash
cli4ai run snowflake connections
`

Commands

`bash
cli4ai run snowflake connections
cli4ai run snowflake warehouses
cli4ai run snowflake databases
cli4ai run snowflake schemas [database]
cli4ai run snowflake tables [database] [schema]
cli4ai run snowflake views [database] [schema]
cli4ai run snowflake columns


cli4ai run snowflake ddl
cli4ai run snowflake sample [limit]
cli4ai run snowflake count
cli4ai run snowflake query
cli4ai run snowflake context
cli4ai run snowflake stages
cli4ai run snowflake formats
cli4ai run snowflake functions
cli4ai run snowflake procedures
cli4ai run snowflake tasks
cli4ai run snowflake streams
cli4ai run snowflake search
`

Security

$3

Store your ~/.snowflake/connections.toml file with restricted permissions:

`bash
chmod 600 ~/.snowflake/connections.toml
`

Consider using Snowflake key-pair authentication instead of passwords for production use. See Snowflake Key-Pair Authentication.

$3

This tool blocks destructive SQL commands (INSERT, UPDATE, DELETE, DROP, etc.) at the application layer. However, this is defense-in-depth only.

Best practice: Use a role with minimal privileges for maximum protection. Snowflake allows creating roles with restricted privileges:

`sql
CREATE ROLE readonly_role;
GRANT USAGE ON WAREHOUSE MY_WH TO ROLE readonly_role;
GRANT USAGE ON DATABASE MY_DB TO ROLE readonly_role;
GRANT USAGE ON ALL SCHEMAS IN DATABASE MY_DB TO ROLE readonly_role;
GRANT SELECT ON ALL TABLES IN DATABASE MY_DB TO ROLE readonly_role;
GRANT SELECT ON FUTURE TABLES IN DATABASE MY_DB TO ROLE readonly_role;
``

The application-layer filtering may have edge cases (e.g., stored procedures, unusual syntax). Database-level permissions are the authoritative security boundary.