Your coding agent in Slack

Slack is where the gateway’s command set is deepest. It connects over Socket Mode, an outbound connection from your machine, so there is no public URL to expose. You talk to the agent in a DM, or in a channel where the bot is present, and it answers only you: the owner named by one member ID.

What has been run on which harness is on the verification log; a feature without a dated row there is unverified.

What works from Slack today

• Approve / Trust session / Reject buttons on a tool call that needs your say-so. An unanswered prompt is rejected after 120 seconds. Approving in Slack or in the dashboard resolves both.
• Per-channel activation: answer every message, only when mentioned, observe quietly, require review first, or stay off (!channel always | mention | observe | review | off).
• An emergency stop: !stop halts the running turn in that thread.
• Keyword commands: status, cron list | pause | resume | remove, spawn run "task", run <spec> for the task runner, and sessions to resume a dashboard conversation.
• A dashboard link on request: !dashboard DMs you a time-limited link.

Set it up

The dashboard does most of it. Open Settings → Channels → Slack and click Create Slack app: the app is created from a pre-filled manifest with Socket Mode and its permissions included. Then:

1. Install the app to your workspace.
2. Paste the two tokens into the same panel: the bot token (xoxb-…, from OAuth & Permissions) and the app-level token (xapp-…, for Socket Mode).
3. Set the owner: your Slack member ID (it starts with U or W). That member is the only one the bot answers.
4. Restart the gateway, then DM the bot:

   warding restart

By hand, the same three values go in the data home’s .env file as SLACK_BOT_TOKEN, SLACK_APP_TOKEN and JUNCTION_OWNER_ID.

Who can reach it

Only the owner. Letting other members in is disabled on purpose, because anyone admitted would act under the owner’s identity on the owner’s machine. In a shared channel, remember that the bot’s replies, including tool output, are readable by everyone in it; the activation mode decides when it speaks, not who reads.

A command on the built-in deny list, or a read of a keystone path such as ~/.ssh, is refused before any button reaches Slack. The security page names each mechanism.

Limits, stated plainly

• Owner-only. One person runs this gateway, as themselves, with their files and credentials. There is no shared or team mode.
• One harness for chat. The docked harness answers every channel; switching is one setting. A spawned subagent can be routed to another installed harness; that is registered, not verified.
• Your box has to stay on. Nothing of ours runs in the cloud.
• Creating jobs from chat (and subagents, and questions the agent asks you mid-turn) relies on the agent’s own tools, which reach kiro-cli only today. On other harnesses, schedule from the dashboard or the CLI; see the schedule page.
• Auto-approve is machine-wide. !yolo on is the same grant as the dashboard toggle, and it still cannot approve what a deny rule refuses.

Approvals: buttons · All ten channels · Full reference publication pending