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

FlagWhat it does
--forceRe-runs setup, overwriting existing template files. Use this after upgrading the CLI if you want the latest templates.

What the wizard collects

PromptUsed for
Snowflake account identifierAll REST API calls and the connections.toml
Admin PATAuthenticates 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 roleThe 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 PATA 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.
ChannelsSlack, Telegram, and/or Discord credentials
ToolsPre-registered tools (e.g. GitHub, Brave Search) that auto-configure credentials
Object provisioningWhether to create Snowflake objects now via the REST API
Egress modeAllowlist (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_schema by default)
  • Image repository (snowclaw_repo)
  • Internal stage (snowclaw_state_stage) — backs the container's persistent volume
  • Secrets — snowclaw_sf_token holds 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_poolCPU_X64_S, 1 node)

Next