goose-slackbot — Talk to goose from Slack

[tlongwell-block]

Add a first-party Slack client for goose: a new crate (crates/goose-slackbot) that lets teams interact with goose directly from Slack channels and DMs.

@mention goose in a channel, get a threaded response — with full tool use, streaming, and per-channel context. No IDE required. No CLI required. Just Slack.

Why this matters

Most AI coding agents are locked inside IDEs or terminals. That's great for individual developers, but it means the rest of your team — SREs, managers, support engineers, anyone who doesn't have the agent installed — can't use it.

Slack is where teams already work. A goose Slack bot turns goose from a single-player tool into a team-wide capability. Anyone in your workspace can ask goose a question, kick off a task, or get help — without installing anything.

As far as we know, there's no self-hosted, bring-your-own-keys, widely-adopted AI agent with a Slack interface today. A couple of competitors offer Slack integrations (Devin, Kilo Code), but they're closed-source or cloud-hosted SaaS. This would make goose the first open-source AI agent you can talk to from Slack.

How it works

The slackbot embeds goose-server as a Rust library — the same backend the desktop app uses, just linked in-process instead of called over HTTP.

Desktop app    →  goose-server (HTTP)         →  Agent → MCP extensions
goose-slackbot →  goose-server (embedded lib)  →  Agent → MCP extensions

This isn't a new execution pathway. It's another consumer of the same goose-server API surface. Same session management, same streaming replies, same tool confirmation protocol, same extension system. The slackbot adds only the Slack-specific layer on top:

• Socket Mode (WebSocket) — no public URL needed, works behind firewalls
• Channel context — channel description, pinned messages, bookmarks, and Canvas-based hints are injected into the system prompt so goose understands the channel it's in
• Thread-based sessions — each Slack thread maps to a goose session; DMs get their own sessions with automatic rotation
• Markdown → Slack formatting — goose outputs standard Markdown, the bot converts to Slack's mrkdwn format
• Access control — channel/user allowlists, per-channel extension gating, and a rule engine for fine-grained tool permissions

What it looks like

1. @mention goose in a channel → goose responds in a thread
2. DM goose directly → conversational back-and-forth
3. Tool calls are displayed in the thread (configurable: per-call messages, a single updating message, or hidden)
4. Channel owners can drop a Canvas file named .goosehints or AGENTS to customize goose's behavior per-channel — no deployment changes needed

Architecture

Single Rust binary. Single container. No sidecar.

The Slack integration uses slack-morphism-rust (Apache 2.0, actively maintained) for Socket Mode, typed API methods, Block Kit, and rate limiting — with zero dependency conflicts against goose's existing tree.

Safety

Self-hosted by design — goose runs in your infrastructure with your own model keys. No code or prompts leave your environment (beyond what you send to your chosen LLM provider).

The bot includes a two-layer access control system:

• Allowlists — control which channels and users the bot responds to, and which MCP extensions are available per channel
• Rule engine — fine-grained, argument-level control over tool execution (e.g., "only allow file writes in repos X and Y," "block shell commands in #general")
• Tool confirmation — every tool call goes through the bot's permission system before execution

Why a rewrite (not a wrapper)

We already run a goose Slack bot internally — a Python service that connects to goose-server over HTTP. Teams use it daily. This proposal rewrites it in Rust and embeds goose-server directly:

	Python (current internal)	Rust (proposed)
Deployment	Two containers + docker-compose	Single binary
Communication	HTTP/SSE over network	In-process function calls
Session mapping	Custom ID → server UUID indirection	Direct session IDs
Maintenance	Separate repo, separate CI, separate language	Same workspace as goose

The Python bot proves the concept works. The Rust rewrite makes it a first-class part of the platform.

What we're NOT doing

• Not building a generic chat framework. This is a Slack client. Discord/Teams/etc. could follow the same pattern later.
• Not adding new agent capabilities. The bot uses goose-server's existing API — no backend changes required.
• Not creating a new execution pathway. This consolidates on goose-server, consistent with the direction of making it the single execution backbone.

[spikewang]

Great idea. I was actually thinking about adding this to Goose and run Goose as a daemon. It seems like there is a goose-server idea mentioned above. Any more details about that? Just like the idea of OpenClaw, why just let Goose be a 24x7 running bot that could constantly work on things...

[laserninja]

I am interested. I am willing to contribute as well. I feel right now there is no enterprise solution for openclaw like app with evaluations, monitoring, etc.