SnowClaw
SnowClaw
GitHub

Secrets & credentials

SnowClaw manages secrets entirely through your local .env file. They are never baked into the Docker image — they're uploaded to Snowflake as individual SECRET objects and mounted into the running container at runtime as environment variables.

How it works

  1. snowclaw setup collects your Snowflake PAT, channel tokens, and tool credentials during the interactive wizard and writes them to .env.
  2. snowclaw deploy and snowclaw push automatically read .env, create or update a Snowflake SECRET for each variable, and regenerate the SPCS service spec to mount them.
  3. At runtime, secrets are available as environment variables inside the container.

What becomes a secret

SourceExampleHow it's handled
Snowflake authSNOWFLAKE_TOKENCreated as a dedicated secret during deploy
Channel credentialsTELEGRAM_BOT_TOKEN, DISCORD_BOT_TOKEN, SLACK_BOT_TOKENAdded via snowclaw channel add, auto-detected per channel
Tool credentialsGH_TOKEN, BRAVE_API_KEYAdded via setup wizard when tools are selected
Custom variablesAny other KEY=value in .envAutomatically becomes a Snowflake secret — no config needed

Any key=value pair you add to .env is automatically uploaded as a Snowflake secret. There's no separate registration step. Just add the variable, run snowclaw push, and it's available in the container.

Updating secrets

# Edit .env with your new or changed values, then:
snowclaw push              # pushes config, workspace, skills, AND secrets
snowclaw push --secrets    # push ONLY secrets (skips file sync for speed)

Both commands update the Snowflake SECRET objects and restart the service to pick up changes.

CUSTOM_ vs. bare custom vars

Variables prefixed with CUSTOM_ are surfaced in the generated service spec and documentation as user-managed secrets. Bare custom variables also become secrets, but without the special-case treatment. Prefix with CUSTOM_ if you want the variable to be obvious as "mine, not SnowClaw-internal" to future-you.

Masking

The Cortex proxy scrubs known secret values from outbound LLM payloads before they reach Cortex. See the Security model page for how the masking walkers handle both OpenAI and Anthropic request shapes.

Variables listed in SNOWCLAW_MASK_VARS (auto-generated in .env) are the ones masked. By default this includes every *_TOKEN and *_API_KEY the CLI knows about, plus everything you added via CUSTOM_.

What does not leave your account

  • .env is gitignored by default — it never ends up in a commit.
  • Secret values are not printed in CLI output.
  • SECRET object contents are never retrievable from Snowflake — they are write-only from the API's perspective.
  • The masking sidecar means even your agent can't accidentally leak them to the LLM.