Forem: Dash

I built a remote control for Cortex Code in Slack so I can step away from my laptop

Dash — Mon, 13 Apr 2026 14:00:00 +0000

Snowflake Cortex Code CLI Meets Slack

Cortex Code CLI is Snowflake's AI coding agent that runs in your terminal. It can write code, execute SQL and DDL scripts, create and deploy data pipelines, generate dashboards, reads & write files, manages git repos and more.

Cortex Code CLI also has a hook system and skill framework that make it extensible so you can build sidecar apps that plug into its lifecycle. I wanted to explore this extensibility by building a Slack bridge: get DM notifications about what the agent is doing, and reply with instructions to steer it, all from your phone. The whole conversation happens in Slack while the agent keeps working in the terminal. No servers, no databases, no cloud infra. Just a Slack bot, some JSON files, and a shell wrapper.

What It Actually Does

It supports two interaction patterns:

Free-text conversations: You type a message in the Slack DM. It lands in a session-specific inbox file. The agent's cron job picks it up on the next cycle and treats it as user input. This is the core of the bridge — you can ask questions (“what's the row count on that table?”), give instructions (“skip that step and move to the next one”), make decisions (“use approach #2”), or redirect the work entirely (“actually, focus on the API layer first”). The agent responds back via Slack.
Notifications: The agent sends you status updates as Slack DMs. “Feature engineering done, 5 tables created.” “Model training complete, 3 models evaluated.” “Blog post committed and pushed.” You see them on your phone and know what's happening without being at the terminal.

Note: This bridge works best with “bypass safeguards” enabled in Cortex Code CLI, which lets the agent execute tools without pausing for terminal confirmations. That's what makes the remote workflow possible; if the agent stopped to ask for permission at the terminal, you'd have to be sitting there anyway.

But understand the tradeoff: bypass safeguards means the agent can execute bash commands, write files, run SQL, and push to git without asking first. You're trusting the agent to do the right thing. The Slack bridge gives you visibility (notifications) and steering (free-text replies), but it doesn't replace the confirmation gate — it replaces the terminal. Use it on repos and environments where you're comfortable with that level of autonomy.

Key Design Decisions

Socket Mode: No public URLs needed. The bot connects outbound to Slack's WebSocket API. Works behind firewalls, no ngrok required.
File-based inbox: Each Cortex Code CLI session gets its own inbox_{session_id}.json. The bridge bot writes to it; the CLI polls it via cron. Dead simple, zero dependencies.
Metadata routing: Every outbound Slack message includes session metadata. When you reply, Slack sends that metadata back. The bridge uses it to write to the correct session's inbox. Multiple sessions, no crosstalk.
Sidecar process: The bridge bot runs as a background process, started automatically by a SessionStart hook. It's not embedded in Cortex Code CLI ; it's a separate Python process that communicates via the filesystem.

The Code

The project has four main files.

1) config.py: Configuration and Session Management

It handles paths, tokens, and multi-session routing.

BRIDGE_DIR = Path.home() / ".cortex-slack-bridge"
INBOX_FILE = BRIDGE_DIR / "inbox.json"
PID_FILE = BRIDGE_DIR / "bridge.pid"

Token lookup follows a priority chain: environment variable > macOS Keychain > config file. Env vars (SLACK_BRIDGE_APP_TOKEN, SLACK_BRIDGE_BOT_TOKEN) are checked first, then Keychain via the security CLI, then ~/.cortex-slack-bridge/config.json as a fallback. The Keychain path means tokens never sit in plain text on disk:

KEYCHAIN_SERVICE = "coco-slack-bridge"

def keychain_get(key: str) -> str | None:
    try:
        result = subprocess.run(
            ["security", "find-generic-password", "-s", KEYCHAIN_SERVICE, "-a", key, "-w"],
            capture_output=True, text=True, timeout=5,
        )
        if result.returncode == 0:
            return result.stdout.strip()
    except (FileNotFoundError, subprocess.TimeoutExpired):
        pass
    return None

Zero new dependencies; just the security CLI that ships with macOS. Session management is minimal: get_session_inbox() returns the inbox path for a session ID, and set_active_session() / get_active_session() track which session the bridge should route messages to when there's no metadata to go on.

2) bridge.py: The Socket Mode Bot

This is the long-running process. It connects to Slack via Socket Mode so when you type in the Slack DM, it captures the text and writes it to the active session's inbox:

@app.event("message")
def handle_dm(event, say):
    user = event.get("user")
    if subtype or user != target_user:
        return

    _append_inbox({
        "type": "reply",
        "text": event.get("text", ""),
        # ...
    })

    say("Message sent to CoCo CLI. Awaiting response…")

Both bridge.py and notify.py append every message to ~/.cortex-slack-bridge/history.jsonl which acts as a permanent audit trail. Inbound DMs, outbound notifications, consumed confirmations — everything gets logged with direction and timestamp.

def _log_history(entry: dict, direction: str):
    try:
        record = {**entry, "direction": direction, "logged_at": time.time()}
        with open(HISTORY_FILE, "a") as f:
            f.write(json.dumps(record) + "\n")
    except Exception:
        pass # history logging done not break core functionality

Three direction values: inbound (user DMs and button clicks), outbound (agent notifications and confirmation requests), consumed (confirmation responses popped from the inbox).

3) notify.py: Sending Messages

This is the outbound side. The main function is send_message() — it sends a plain DM or a color-coded message (blue for status, green for success, yellow for warnings, red for errors). Every message includes session metadata so replies route back correctly:

metadata = {
    "event_type": "cortex_bridge",
    "event_payload": {"session_id": sid},
}

There's also a send_confirmation() function that sends Approve/Deny buttons and polls the inbox for a response. It's used by coco-bridge confirm for scripted gate checks.

4) bin/coco-bridge: The Shell Wrapper

A bash script that makes everything easy to use from Cortex Code CLI's skill system:

coco-bridge start          # Start the bridge bot
coco-bridge stop           # Stop it
coco-bridge status         # Check if running
coco-bridge send "message" # Send a DM
coco-bridge send "msg" - type success # Color-coded
coco-bridge confirm "question" # Approve/Deny buttons
coco-bridge inbox          # Read inbox contents
coco-bridge history        # Last 20 messages (audit log)
coco-bridge history 50     # Last N messages
coco-bridge setup-keychain # Store tokens in macOS Keychain
coco-bridge clear-keychain # Remove tokens from Keychain
coco-bridge logs           # Tail the log file

It auto-detects the project's virtualenv, manages the PID file, and dispatches to the Python modules.

Why This Works

Most AI coding agents don't expose lifecycle hooks as in programmatic entry points where your own code runs at specific moments in the agent's execution. Cortex Code CLI does! It has a hook system that fires shell commands at session start, after every tool call, on user input, and at session end. Combined with a skill framework that lets you teach the agent new behaviors via markdown files, you get a real extensibility contract. This Slack bridge exists entirely because of that, and it's worth understanding the two mechanisms that make it work.

The Hook System

Cortex Code CLI has a lifecycle hook system defined in ~/.snowflake/cortex/hooks.json. You can register shell commands that fire at specific points:

SessionStart: runs when a new session begins (before the agent does anything)
PostToolUse: fires after every tool call (bash, file write, SQL execution, etc.)
UserPromptSubmit: fires when the user sends a message
Stop: fires when the session ends
SubagentStop: fires when a background agent completes

Each hook is a shell command with a configurable timeout. The stdout from SessionStart hooks gets passed to the agent as context, which is how the bridge tells Cortex Code CLI “hey, I'm running, ask the user if they want Slack enabled.”

This is a big deal. It means you can build sidecar applications that plug into Cortex Code CLI's lifecycle without modifying the CLI itself.

The Slack bridge uses SessionStart to auto-launch. But you could just as easily build:

A PostToolUse hook that logs every tool call to a database (audit trail)
A UserPromptSubmit hook that captures conversation history (flight recorder)
A Stop hook that sends a session summary to Slack or email

Setting It Up

Prerequisites

Python 3.10+
A Slack workspace where you can install apps
Cortex Code CLI

Create the Slack App

Go to api.slack.com/apps and create a new app
Under Socket Mode, enable it and create an App-Level Token with connections:write scope. Copy the xapp-… token.
Under OAuth & Permissions, add these Bot Token Scopes: chat:write to send DMs, im:history to read DM history, im:read to view DM channels, im:write to open DM channels
Under Event Subscriptions, enable events and subscribe to the message.im bot event
Under Interactivity & Shortcuts, enable interactivity (no URL needed for Socket Mode)
Install the app to your workspace. Copy the Bot User OAuth Token (xoxb-…).
Find your Slack User ID: click your profile picture in Slack, click the three dots, “Copy member ID”

NOTE: the app-level token, bot user oauth token and your Slack member ID will be used later under Configure Tokens section.

Install the Bridge

git clone https://github.com/iamontheinet/cortex-code-cli-slack-bridge.git \
  ~/Apps/cortex-code-cli-slack-bridge
cd ~/Apps/cortex-code-cli-slack-bridge
python3 -m venv .venv
.venv/bin/pip install -e .

Install Cortex Code CLI Skill

Cortex Code CLI has a skill system that lets you teach the agent new behaviors via markdown files. The repo includes the Cortex Code CLI skill file that teaches the agent how to manage the bridge. For example, when to poll, how to format messages, how to activate and deactivate.

Copy it to your skills directory:

mkdir -p ~/.snowflake/cortex/skills/slack-bridge
cp skill/SKILL.md ~/.snowflake/cortex/skills/slack-bridge/SKILL.md

The Slack bridge skill defines:

Trigger phrases: “slack on”, “enable slack”, “/slack”, etc.
Activation flow: what to do when the user opts in
Message routing: how to handle inbox entries, when to send notifications
Deactivation: how “slack off” tears down the polling

When you say “slack on”, the skill instructs the agent to:

Create a session-scoped cron job that polls the inbox every minute
Send an activation message to Slack
Start routing questions and status updates through Slack instead of the terminal

The cron pattern here is worth calling out. Cortex Code CLI's cron_create tool lets you schedule prompts that fire on a schedule — and they're session-scoped, meaning they die when the session ends. The bridge uses this as a heartbeat: every minute, a “Slack inbox check” prompt fires. The skill tells the agent to read the inbox file, and if it's empty, sleep 30 seconds and check again. Two checks per cron fire gives you ~30-second worst-case latency without doubling the cron frequency or adding a file watcher. It's a cheap way to give an agent a polling loop — just a cron job and a JSON file. The skill also handles “slack off” to disable the bridge mid-session.

Configure Tokens

The recommended approach stores tokens in macOS Keychain:

coco-bridge setup-keychain
# Prompts for app token, bot token, and user ID
# Stores them in Keychain under the "coco-slack-bridge" service

If you already have a config.json, setup-keychain reads from it, migrates to Keychain, and offers to delete the file.

Alternatively, use a config file or env vars:

# Config file approach
mkdir -p ~/.cortex-slack-bridge
cp config.json.example ~/.cortex-slack-bridge/config.json
# Edit with your actual tokens

# Or env vars
export SLACK_BRIDGE_APP_TOKEN="xapp-1-A0…"
export SLACK_BRIDGE_BOT_TOKEN="xoxb-…"
export SLACK_BRIDGE_USER_ID="U02M…"

Start and Test

# Start the bridge
bin/coco-bridge start

# Send a test message
bin/coco-bridge send "Hello from the bridge!"

# Test a reply - type something back in the Slack DM, then check:
bin/coco-bridge inbox

Wire Up the SessionStart Hook

Add this to ~/.snowflake/cortex/hooks.json so the bridge auto-starts with every Cortex Code CLI session:

{
  "hooks": {
    "SessionStart": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "/Users/YOUR_USERNAME/.cortex-slack-bridge/start-hook.sh",
            "timeout": 10,
            "enabled": true
          }
        ]
      }
    ]
  }
}

Copy the start hook script:

cp demo-start-hook.sh ~/.cortex-slack-bridge/start-hook.sh
chmod +x ~/.cortex-slack-bridge/start-hook.sh

The Beauty of Extensibility

The whole project is ~300 lines of Python plus a shell wrapper. No servers, no databases, no cloud infra. It extends Cortex Code CLI with a mobile-friendly communication layer so you can kick off a task, walk away, get updates, reply with instructions, all from Slack.

But the bigger takeaway isn't the Slack bridge itself, it's that Cortex Code CLI is built to be extended this way. Hooks give you lifecycle access. Skills give you behavioral control. The filesystem gives you a dead-simple IPC layer. This bridge is one example; the pattern works for any sidecar you can imagine: audit loggers, custom approval gates, integration bridges to other tools.

Stay Connected

Thank you for your time. I hope you found this blog both educational and inspiring. The code can be found here.

Clone it, plug in your Slack tokens, and build something on top of it. The Cortex Code CLI is waiting for your hooks. If you're experimenting with this workflow or planning to, I'd love to hear what you're building.

Connect with me on LinkedIn for more demos as well as AI product & feature updates.

Hot off the press -- Snowflake Cortex Code in Snowsight is now GA!

Dash — Thu, 26 Mar 2026 18:40:50 +0000

Building and scaling AI apps natively on your data just got a massive upgrade.

Here is what is included in this release:

⚡ Rapid prototyping to production: execute large, multi-step projects directly in Snowsight.
🔒 Enterprise-grade governance: built-in controls and observability for regulated environments.
💸 Cost-aware automation: specialized skills for cost optimization and agentic ML workflows.
🪟 Cross-platform CLI: native Windows support removes friction for engineering teams.

🙌 My absolute new favorite in CLI: Agent Teams!

Here's what I tried: "Build a Streamlit chat app in a new folder that streams responses from the Cortex Agent. Use a team of 3 agents (client, UI, config) with a shared event contract defined upfront to avoid integration mismatches."

🤯 I'm still blown away by how well the Agent Teams handled that shared event contract. If you had a team of agents to automate your workflow today, what's the first project you'd assign them? Let's discuss in comments👇

🔗 Get started in mins: https://www.snowflake.com/en/developers/guides/getting-started-with-cortex-code-cli/

Let's learn together!

[DYK with Dash] Want a policy enforcement layer over your AI coding assistant?

Dash — Thu, 26 Mar 2026 00:51:02 +0000

🙌 Snowflake Cortex Code CLI has a programmable hooks system that fires on 11 lifecycle events -- PreToolUse, PostToolUse, SessionStart, Stop, and more. You write a shell script, and if it returns exit code 2, the operation is HARD BLOCKED.

↳ Validate every bash command before it runs
↳ Block writes to protected files
↳ Log every tool call for audit
↳ Inject context at session start

This is guardrails-as-code for AI-assisted development.

Share this with your platform team -- they need to see this 👇

📖 Get started: https://www.snowflake.com/en/developers/guides/getting-started-with-cortex-code-cli/

Let's learn together!

[DYK with Dash] Build your own AI sub-agents with... Markdown?!

Dash — Tue, 24 Mar 2026 14:23:17 +0000

🙌 Drop a Markdown file with YAML frontmatter into .cortex/agents/ and Snowflake Cortex Code turns it into a fully functional specialized sub-agent with scoped tool access.

↳ Define a code-reviewer agent that only has Read access
↳ Create a migration-checker with Bash + SQL
↳ Share them with your team through version control

That's it. Your team's best practices, encoded as agents.

What custom agent would you build? 👇

📖 Get started: https://docs.snowflake.com/en/user-guide/cortex-code/cortex-code-cli

Let's learn together!

CortexCode #Snowflake #AI #Developers #DataEngineering #DevTools

Data governance just became a conversation, not a workflow.

Dash — Fri, 20 Mar 2026 14:22:04 +0000

🤔 If you've ever tried to get a full picture of your governance posture, you know the drill -- run classification in one place, write masking policies
somewhere else, dig through access history six months ago, and still not really know what's covered.

🙌 We built something to fix that. Data Governance Skills for Snowflake Cortex Code let you govern your data by just... asking.

"What's my governance maturity score?" gives you a 0-5 score across classification, protection, and access monitoring. Per database. With the actual gaps called out.

🤯 The thing I like most -- these aren't generic AI prompts hoping the SQL is right. There are 100+ verified query patterns under the hood, built
specifically for governance views.

Classification, masking, row access policies, data quality via DMFs, lineage with impact analysis -- all in natural language, all native to Snowflake Horizon Catalog. No external catalog to sync. No metadata that's hours behind.

A data steward can now do in one conversation what used to be a sprint across multiple teams!

Available now in Cortex Code CLI. Check it out and let me know what you think: https://docs.snowflake.com/en/user-guide/cortex-code/cortex-code-cli

[DYK with Dash] Git branching... but for AI conversations?!

Dash — Thu, 19 Mar 2026 14:13:18 +0000

🤯 Type '/fork' mid-conversation in Snowflake Cortex Code and it creates a branch of your session at any point you choose. Try a risky refactor, explore a wild idea -- and if it goes sideways, your original session is still right there waiting for you.

↳ '/fork' -- branch from any message
↳ '/fork my-experiment' -- name it for easy recall
↳ '/rewind 3' -- or just roll back 3 messages

This is git-branch thinking applied to your AI workflow. Experiment fearlessly!

Try it: '/fork' your next risky experiment and tell me what you explored 👇

Get started: https://docs.snowflake.com/en/user-guide/cortex-code/cortex-code-cli

Let's learn together!

CortexCode #Snowflake #AI #Developers #DataEngineering #Productivity

[DYK with Dash] Cortex Code has a secret weapon most people walk right past!

Dash — Thu, 19 Mar 2026 00:34:54 +0000

❄️ Type #DB.SCHEMA.TABLE directly in your Snowflake Cortex Code prompt and BOOM -- it auto-injects the full column metadata, primary keys, row count, and sample rows into context. No more copy-pasting DESCRIBE output. No more guessing column names.

👉 Just prefix any fully-qualified table name with # and the agent instantly knows your schema
👉 Autocomplete kicks in after you type #
👉 Works with any table in your Snowflake account

Stop manually feeding context. Let the CLI do it for you!

Try this right now: type # and pick a table -- then drop your result in the comments 👇

📖 Docs: https://docs.snowflake.com/en/user-guide/cortex-code/cortex-code-cli