A code channel is a room with a clock on it
Slack Code is how agents and people work together to build with AI in Slack. The place it happens is a code channel: a temporary channel, created automatically by a supported AI agent, designed for multiplayer use cases (Slack's help center). One opens when you mention the agent in a channel or DM, and the Agents & tools tab on desktop can start one by hand. The agent names it after your first request. Once you are inside, you can add people and other agents.
The clock is the part to know before you invite anyone. Close the channel when the work lands, or let it drop out of the sidebar after seven days of inactivity. Slack says over 70% of code channels spin up and close within a single day, from idea to merged PR (Slack Code launch).
What the room shows while the agent works
Six statuses sit in the sidebar: Working, Idle, Needs attention, Done, Inactive, Archived. The artifact pane collects a code diff, a canvas document, a live HTML view and a list of the files and links shared in the channel. Everyone in the room reads the same screen, so a teammate can flag a wrong assumption while the agent still holds the work.
After the archive, the conversation stays readable
Archived: the channel messages remain available to view and search, but you can't send new messages or prompts. Slack's launch post calls the archived channel "like an audit log in Slack for future reference", which is a fair description of what is kept.
Slack also puts a control in the same place. High-stakes changes can route to a person for a fast approval, right in the channel, and code channels carry the same trust foundation and visibility options as regular channels (Slack's help center). A team that reads that and stops has a fair case that somebody is watching.
Two questions, and the one the archive cannot answer
Did we see it? The channel answers that: the diff, the status, the messages, the person who said go.
Was it allowed? Only for the calls somebody stopped. A card exists because a rule held the call. The calls a rule let through leave no card. No rule text is kept in the archive either, so an archived channel cannot tell you whether the agent was cleared to send from the ops mailbox or was never asked at all.
That gap is small for a coding agent, because the diff is the reviewable unit and a person merges it.
An agent whose work is not a diff
Slack launched Slack Code alongside Anthropic, Cognition, GitHub, OpenAI and Vercel. The agents its help center lists as able to create code channels are all engineering tools: Claude, CodeRabbit, DataDog, Devin, Factory, GitHub Copilot, Lovable, Mistral Vibe, NanoClaw, Replit, Rhythms and Vercel.
Now hand the same team an agent for the ops mailbox and the ticket tracker. Its output is a send or a status change, with no diff to comment on and no preview to open. What the team wants to know the morning after is which of those calls ran with a rule behind them, and an archived channel is silent on it.
The file that answers it
Kortix keeps the answer in the project repo. agents.<name>.connectors takes all, none or a list and settles what the agent reaches. policies matches a <connector>.<tool> path, globs included, first match wins, and each rule is always_run, require_approval or block.
Two keys cover the rest. policy.default_mode decides every call no rule matched, and approvals.ttl sets the wait on a held call, clamped from 5 minutes to 30 days and 24 hours when the key is missing or malformed (manifest reference). Four blocks, each walked through in the kortix.yaml behind a Slack agent, line by line.
The order matters as much as the rules: the agent's grant, then project rules, then the connector's own policies, then sensitive: true on the connector, then policy.default_mode. A call the agent cannot reach never runs, whatever the policy says.
Because the file lives in git, a widening shows up as a diff. A grant goes from a list to all, a require_approval rule disappears, a TTL drops from 4h to 15m. Those are the lines that turn a held write into an unattended one, and a reviewer reads them in the approval-gate walk-through before the merge.
Read the file against the calls you expect
The read-only auditor at Kortix-seo/slack-agent-grant-audit does that read. audit.py takes a manifest and a list of calls, resolves each one through the same five checks, and prints the effect, the decision and the rule that made it, plus the wait resolved for every held call. It calls nothing and holds no credential, so it fits in a change-request check.
On its example project, an ops bot with default_mode: risk, a block on gmail.send_email and a 4h TTL, eight calls resolve to a decision and a rule: gmail.send_email blocked by project rule #1, github.delete_repo blocked by project rule #3, and three held calls each carrying the 4h wait.
What a Kortix agent does in Slack
Connect Slack to a project and a message in a thread starts a session. The agent works on its own cloud computer and replies in the same thread (Kortix channels). It does not create a code channel, because Slack limits code-channel creation to the agents on its supported list. The work lands where the team already talks, and the permission file stays where the work runs.
Before the first mention, write down the calls the bot will actually make, each with its effect. That list plus the manifest is what the audit turns into answers a reviewer can sign, and it is the same list that tells you which rows of the config still need a rule.