Setup wizard
snowclaw setup is the interactive wizard that scaffolds a new SnowClaw project. Run it once per project, in a fresh directory.
Usage
mkdir my-openclaw && cd my-openclaw
snowclaw setup
Bare snowclaw (with no subcommand) also defaults to setup.
Flags
| Flag | What it does |
|---|---|
--force | Re-runs setup, overwriting existing template files. Use this after upgrading the CLI if you want the latest templates. |
What the wizard collects
| Prompt | Used for |
|---|---|
| Snowflake account identifier | All REST API calls and the connections.toml |
| Admin PAT | Authenticates the admin role for provisioning. Should be ROLE_RESTRICTION-scoped to the admin role. |
Admin role (default: SYSADMIN) | The role the CLI uses on your machine to create the database, schema, secrets, compute pool, network rules, and EAI. Not the role the container runs under. See Snowflake privileges for the full privilege matrix. |
| Runtime role | The low-privilege role that owns the SPCS service. You create this role yourself (once per Snowflake account) and grant it to the admin role before running setup. Setup verifies it exists and bails with copy-pasteable SQL if it doesn't. See Snowflake privileges. |
| Runtime PAT | A second PAT, ROLE_RESTRICTION-scoped to the runtime role. Setup prints the exact ALTER USER ... ADD PROGRAMMATIC ACCESS TOKEN command and prompts for the token. Stored as the {prefix}_sf_token Snowflake secret and bound into both containers. |
| Channels | Slack, Telegram, and/or Discord credentials |
| Tools | Pre-registered tools (e.g. GitHub, Brave Search) that auto-configure credentials |
| Object provisioning | Whether to create Snowflake objects now via the REST API |
| Egress mode | Allowlist (default) or unrestricted outbound (opt-in behind a red-warning confirm) |
Two PATs: one on your machine (admin), one in the service (runtime). The admin PAT is never uploaded to Snowflake; the runtime PAT is the only Snowflake credential that lives inside the containers. A compromise of the runtime PAT only grants runtime-role privileges. See Security model for how this shrinks the blast radius of an agent-side compromise.
What the wizard creates
After setup finishes, your project directory looks like this:
my-openclaw/
├── .snowclaw/
│ ├── config.json # version, timestamp, prefix, tools
│ └── network-rules.json # approved egress hosts
├── .env # secrets (gitignored)
├── .gitignore
├── openclaw.json # providers, channels, agents, tool policy
├── connections.toml # Snowflake PAT connection (gitignored)
├── build-hooks/ # optional user .sh scripts
└── skills/
├── cortex-code/
└── snowclaw/
And, if you opted into provisioning, these Snowflake objects:
- Database and schema (
snowclaw_db.snowclaw_schemaby default) - Image repository (
snowclaw_repo) - Internal stage (
snowclaw_state_stage) — backs the container's persistent volume - Secrets —
snowclaw_sf_tokenholds the runtime-scoped PAT (not the admin PAT), plus per-channel, per-tool, and per-custom secrets - Network rule (
snowclaw_egress_rule) - External access integration (
snowclaw_external_access) - Compute pool (
snowclaw_pool—CPU_X64_S, 1 node)
Next
- Deploy when you're ready to push to Snowflake.
- snowclaw dev to iterate locally first.