SNOWFLAKE CORTEX CODE: A SHALLOW DIVE

Install

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

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.

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/

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.”

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)

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

That’s the “blessed” surface area.

See appendix for undocumented environment variables that impact 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.”

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.

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

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.

And the skill loader supports both .cortex/skills and .claude/skills layouts.

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.

Undocumented Environment Variables