# Slack Code archives the room, an open-source file decides the call

> Slack Code gives a team a code channel per task, an agent working in the open, and an archived record of what was said. Kortix is the open-source AI Operating System, and it keeps the other record in a git repo you own: the grants and policies that decide which tool calls run without a person.

URL: https://agentsinslack.com/slack-code-vs-slack-agent

## Slack Code and a runtime you own, side by side

Both answer inside Slack. They record different things.

| | Kortix (recommended) | Slack Code |
| --- | --- | --- |
| Open source | Yes. Read it, fork it, audit it. | No. A Slack product. |
| What the room holds | The thread, the reply, a card for each held call. | Messages, code diff, canvas, HTML view, files and links. |
| The question it settles | Whether a call was allowed, and which rule decided. | Whether the team saw the work happen. |
| A call that needs a person | Stops before the provider sees it, then a card. | Routes the high-stakes change to a person in the channel. |
| Where the rule lives | `kortix.yaml` in the company repo, read as a diff. | The partner agent's own product; the channel keeps no rule text. |
| Where the agent runs | One isolated sandbox per session, its own machine and branch. | The partner agent, installed from the Slack Marketplace. |
| After the work ends | The session and its record stay; the config stays in git. | Channel archived and searchable, new prompts off. |
| Who can open it | Per-resource permissions for people and agents. Roles, groups, and an audit trail. | Anyone the channel's visibility allows. |

## Eight calls, resolved

`audit.py`

```
call                       effect       decision          decided by
kortix_slack.post_message  write        require_approval  policy.default_mode risk: a write call needs approval (4h)
gmail.search_threads       read         allow             project rule #2 gmail.search_* -> always_run
gmail.send_email           write        block             project rule #1 gmail.send_email -> block
linear.list_issues         read         allow             project rule #4 linear.list_* -> always_run
linear.create_issue        write        require_approval  connector linear is sensitive: unmatched calls need approval (4h)
github.list_pull_requests  read         allow             connector github rule #1 list_* -> always_run
github.merge_pr            write        require_approval  connector github rule #2 * -> require_approval (4h)
github.delete_repo         destructive  block             project rule #3 github.delete_repo -> block
```

Source: https://github.com/Kortix-seo/slack-agent-grant-audit

The auditor's own output on the example Slack project: each call with its effect, its decision and the rule that decided it.

## 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](https://slack.com/help/articles/54310833022355-Build-with-AI-as-a-team-using-Slack-Code)). 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](https://slack.com/blog/news/slack-code-channels-for-agents)).

## 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](https://slack.com/help/articles/54310833022355-Build-with-AI-as-a-team-using-Slack-Code)). 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](https://kortix.com/docs/project/manifest)). Four blocks, each walked through in [the kortix.yaml behind a Slack agent](/kortix-yaml-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](/slack-approval-gates) before the merge.

## Read the file against the calls you expect

The read-only auditor at [Kortix-seo/slack-agent-grant-audit](https://github.com/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](https://kortix.com/markdown/channels.md)). 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.

## Questions Slack Code raises

Short answers to the three that come up first.

### What is a Slack code?

Slack Code is the Slack feature where agents and people build with AI together. A supported agent opens a code channel for one task, so the team plans and prompts it together instead of in separate direct messages.

### How to get Slack code?

Mention a supported agent in a channel or DM and one starts. It is available on all plans with a supported agent installed, rolling out gradually, and some apps need a paid account; the Agents & tools tab can also create one.

### Can my boss read my Slack DMs?

Admins cannot browse DMs in the Slack app. Free and Pro owners can ask Slack to export all channels and DMs only with valid legal process, member consent or a legal requirement. Business+ and Enterprise owners apply for a self-serve export, as needed and permitted by law ([Slack's export guide](https://slack.com/help/articles/204897248-Guide-to-Slack-import-and-export-tools)).

## Run the agent whose permissions you can read

Connect Slack, then set the gates before the first mention.

[Try Kortix](https://kortix.com) · [Read the four blocks](https://agentsinslack.com/kortix-yaml-slack-agent)