Skip to main content
Interact with Slack workspaces via the slackcli binary installed on the gateway host. Agents pass slackcli arguments directly; the tool enforces a command-level permission layer before executing anything.

Installation

Install this tool individually:
Or install all tools from the toolkit:

Configuration

When no config is provided at all, a built-in denylist is applied automatically: auth login, auth login-browser, auth logout, auth remove, auth extract-tokens, auth parse-curl, update. These are auth-mutating operations that agents should not run autonomously. When any config is provided (even just timeout), the default denylist is replaced entirely by whatever you configure in denyCommands.

Prerequisites

Permission Model

Access is controlled at the command path level. A command path is the leading 1–2 subcommand tokens before any flags. Matching is by prefix: "messages" in a deny list blocks messages send, messages react, and messages draft. "messages send" blocks only send. Precedence: deny beats allow. Checked in order:
  1. denyCommands — if any entry matches → rejected immediately
  2. allowCommands — if set and no entry matches → rejected
  3. Otherwise → permitted

Config Examples

Read-only agent (can read everything, cannot send or mutate auth):
Strictly scoped agent (can only list channels and read history):
Notification agent (can only send messages, nothing else):
React-only agent (can only add emoji reactions):
Full access except sending (everything allowed except send and draft):

Per-Agent Configuration (pluginConfigs)

Use beige’s pluginConfigs to give different agents different Slack permissions:

Available Commands

conversations

messages

auth

Error Reference

Implementation Details

  • Target: Gateway (runs on the host, not in the sandbox)
  • Dependency: slackcli binary
  • Stateless: Each invocation spawns a fresh slackcli process