Snowflake Cortex Code: A Shallow Dive

(If it feels like Claude Code… it might basically be that.)

Snowflake shipped a new coding-agent CLI called Cortex Code CLI. It’s an “agentic shell” that’s tightly integrated with your Snowflake account: it understands Snowflake Auth, can run SQL against your warehouse, validates dbt models, and generally tries to behave like a Snowflake-native developer buddy. (Snowflake Documentation)

And if you try it for five minutes and go: “wait… why does this feel like Claude Code?” — you’re not imagining it.

Snowflake’s own docs basically wink at Cortex Code’s lineage: Cortex Code CLI supports .claude/… paths alongside .cortex/… for skills and settings. That’s not an accident. (Snowflake Documentation)

So the best way to understand Cortex Code isn’t “clone vs not clone.”

It’s:

What’s different when you take a Claude-Code-like agent loop and harden it for Snowflake’s world?

This post is that shallow dive:

• what it is
• how it’s shipped
• why the conversations “feel heavier”
• what the system prompt situation looks like in practice
• and how to customize it (including a few leverage points the docs don’t really advertise)

What Snowflake actually released

Snowflake describes Cortex Code as an AI agent integrated into the Snowflake platform, optimized for data engineering, analytics, ML, and agent-building tasks, with deep awareness of Snowflake RBAC and schemas.
It’s delivered in two places:

• Cortex Code in Snowsight (web UI, currently preview)
• Cortex Code CLI (terminal, generally available)

The CLI release itself went GA on Feb 02, 2026. 

Familiar Skills

The official Cortex Code extensibility docs explicitly support Claude-ish project layout.

Skills: .cortex/skills and .claude/skills both work

The docs list skill locations like:

• project: .cortex/skills/ or .claude/skills/
• user: ~/.snowflake/cortex/skills/ or ~/.claude/skills/ (Snowflake Documentation)

That’s not just “inspired by.” That’s straight-up compatibility.

‍

Hooks: .claude/settings.json and .claude/settings.local.json are supported

Hook configuration can live in:

• .claude/settings.local.json or .cortex/settings.local.json
• .claude/settings.json or .cortex/settings.json
• plus global hooks in ~/.snowflake/cortex/hooks.json

Also: the hook event table in Snowflake docs includes this absolute gem:‍

Stop — “When user stops Claude” (Snowflake Documentation)

That’s… a tell.

Getting started

Install

Snowflake’s official install is a curl-to-shell installer that drops the cortex executable into ~/.local/bin by default: (Snowflake Documentation)

curl -LsS <https://ai.snowflake.com/static/cc-scripts/install.sh> | sh

Unofficial Nix install‍

You can try Cortex Code immediately without installing anything:
nix run github:xorq-labs/cortex-cli-nix --refresh

Or install it declaratively via nix profile (with support for upgrades, rollbacks, and version pinning):
nix profile install github:xorq-labs/cortex-cli-nix

Compared to curl | sh, the Nix flake offers reproducible builds, explicit version pinning, and clean uninstall/rollback semantics, and integrates naturally with NixOS and Home Manager setups. The package is automatically updated as Snowflake releases new Cortex Code builds, but remains entirely unofficial and community-supported.

Connect to Snowflake

On first run, cortex launches a setup wizard and asks you to pick or create a connection.

It reads from ~/.snowflake/connections.toml, the same file used by Snowflake CLI (snow).

Authentication

The default auth method is browser-based auth (externalbrowser), and Snowflake also recommends PATs for scoped access.

Models + cross-region inference

Cortex Code CLI supports Claude models like:

• claude-sonnet-4-5
• claude-4-sonnet
• claude-opus-4-5

You’re expected to use Cortex cross-region inference. 

ALTER ACCOUNT SET CORTEX_ENABLED_CROSS_REGION = 'AWS_US';

Snowflake’s cross-region inference doc clarifies what this is: it routes inference to a different region when your default region can’t serve a given model, and it’s controlled by the account parameter CORTEX_ENABLED_CROSS_REGION. 

What it ships: familiar core, Snowflake-flavored packaging

From my own inspection, Cortex Code CLI is distributed as a native executable (and it looks like a Bun-packaged single-file app, very similar to Claude Code’s “native” distribution pattern).

But Snowflake ships it in a more modular bundle than Claude Code typically does.

In the Cortex package I looked at, it wasn’t just one cortex binary. It also included:

• a small browser helper binary (used for automation / web context)
• an fdbt binary (a “dbt” foundation tool for data workflows)
• a pile of bundled skills (Snowflake workflow packs)
• Some new tools:
  
  • SnowflakeSqlExecute - Execute or validate SQL queries against Snowflake
  • DataDiff - Compare two Snowflake tables for row-level differences
  • dbt-verify - DBT project validation task (lineage, list etc)
  • Cortex e.g. cortex artifact create notebook)

Snowflake’s docs do explicitly call out that the CLI includes built-in Snowflake skills and supports extension via tools, skills, subagents, hooks, profiles. (Snowflake Documentation)

So even if Snowflake doesn’t document “here are the extra binaries we ship,” the product shape is: agent core + Snowflake-specific tooling (cortex, fdbt)+ curated sklls.

That’s the first “why it feels heavier”: the distro itself is heavier.

Conversation traces: the “hello” biopsy

Let’s use the smallest possible prompt:

Test prompt: "hello"

Transcript format is where the difference really shows

Claude Code: JSONL log

Claude Code logs as newline-delimited JSON (JSONL) — one record per line/turn. It’s stream-friendly and diff-friendly.

Cortex Code: single JSON session file

Cortex stores sessions as a single JSON document under:

~/.snowflake/cortex/conversations/ (Snowflake Documentation)

This isn’t just “file format preference.” It reflects different priorities:

• JSONL is a log
• a big JSON session object is more like a “snapshot”

System prompts: Cortex is loud about its guardrails

This is the part that makes Cortex Code feel heavy even when it’s being brief.

In the session artifacts you captured, Cortex prepends every user message with a stack of <system-reminder> blocks:

• plan mode rules (504)
• empty todo reminder (371)
• todo discipline (539)
• file creation policy (636)
• failure patterns (277)
• built-in command docs (3611)
• browser automation guidance (610)
• active Snowflake connection context (293) (dynamic)

Whether those are literally sent to the model every turn or partially cached/compacted, the intent is clear:

Cortex is trying to make every turn self-contained and policy-governed.

That’s an enterprise product posture.

Claude Code has guardrails too, but it keeps them mostly out of the transcript and out of your face.

So if you’re injecting ~7KB of policy blobs per turn, you’re paying for that “helpfulness” one way or another (tokens, cache tokens, latency, or all three). Even if Snowflake does prompt caching behind the scenes, the baseline footprint is still real.

This is what I mean by “the cost of customization on top of vanilla Claude.”

Cortex isn’t just “Claude answering your prompt.” It’s “Claude + Snowflake governance wrapper + connection context + tool discipline.”

Here is the link to a complete conversation: gist
‍

Customizations

Snowflake actually gives you a lot here — but it’s spread across a few surfaces.

1) Documented knobs

Settings files

Snowflake documents the main config directory and files:

• ~/.snowflake/cortex/settings.json
• ~/.snowflake/cortex/permissions.json
• ~/.snowflake/cortex/mcp.json
• ~/.snowflake/cortex/conversations/ (session files) (Snowflake Documentation)

Environment variables (official list)

The settings docs list a small set of env vars:

• SNOWFLAKE_HOME
• CORTEX_AGENT_MODEL
• CORTEX_ENABLE_MEMORY
• COCO_DANGEROUS_MODE_REQUIRE_SQL_WRITE_PERMISSION (Snowflake Documentation)

That’s the “blessed” surface area.
See appendix for undocumented environment variables that impacts agent behavior.

Permissions + modes

Snowflake documents three modes (Confirm / Plan / Bypass), plus permission caching, plus the --private flag to disable saving conversations. 

If you’re using this inside real repos / real accounts, that --private flag is not optional. It’s the difference between “agent helped me” and “agent left a paper trail in my home directory forever.” (Snowflake Documentation)

2) Hooks

Hooks are where Cortex becomes “programmable.”

Snowflake documents hook events like:

• PreToolUse, PostToolUse
• PermissionRequest
• UserPromptSubmit
• SessionStart, SessionEnd
• Stop, SubagentStop, Setup, etc.

And the hook config paths explicitly support .claude/… and .cortex/… files.

One nerdy observation that matters if you’re migrating workflows:

Claude Code’s hook system includes an event named PostToolUseFailure in its reference docs. (Claude Code)

Snowflake’s documented hook event list does not include PostToolUseFailure. (Snowflake Documentation)

So either:

• Snowflake forked/pinned a version before that event existed, or
• Snowflake intentionally removed/renamed it, or
• it exists but isn’t documented (possible, but I’m going off the public docs)

I’d treat it as: expect slight drift vs upstream Claude Code workflows.

3) Skills: Snowflake’s preferred extension model

Snowflake says Cortex Code CLI includes built-in Snowflake skills for things like agent creation, ML, data engineering, governance. 

[list all skills]

And the skill loader supports both .cortex/skills and .claude/skills layouts. (Snowflake Documentation)

Here are the bundled skills:

• !agent-optimization
• !cortex-code-guide
• !cost-management
• !data-governance
• !developing-with-streamlit
• !machine-learning
• !openflow
• !semantic-view-optimization
• !skill-development
• !snowflake-postgres

Snowflake leans on domain packs (“skills”) you can version, bundle, and distribute

‍

Takeaways

Cortex Code feels like Claude Code because it shares the same mental model: a local agent loop, skills, hooks, project-scoped configuration, and conversational state. The compatibility with .claude/ paths isn’t accidental — it lowers friction for users already familiar with that ecosystem.

But Cortex isn’t trying to be a general-purpose coding agent.

It’s a governed, Snowflake-aware wrapper around that agent loop:

• It injects policy and guardrails aggressively.
• It binds deeply to Snowflake auth, RBAC, and schemas.
• It bundles domain-specific tools (SQL execution, table diffing, dbt validation).
• It prioritizes enterprise safety and reproducibility over minimalism.

That’s why it feels “heavier.” It is heavier — by design.

If you’re a Snowflake-first team, that weight is a feature. You get tighter integration, fewer auth hacks, and a more opinionated workflow aligned to data engineering inside Snowflake.

If you’re used to vanilla Claude Code, expect:

• Slight behavioral drift (especially around hooks and planning).
• Larger baseline prompt context.
• More system scaffolding per turn.
• A distribution that bundles Snowflake workflows by default.

Appendix

Undocumented Environment Variables (scrollable):