Work from Slack

The Slack integration connects a Slack thread to an agent conversation in boxes.dev. After setup, a request to @boxes.dev will start Codex or Claude Code on a new devbox, and follow-up mentions in that Slack thread will go to the same agent conversation.

Connect your workspace and account

Start with a boxes.dev project whose saved environment is ready to run your code. Your team needs one Slack connection, and each person who starts work needs to link their own Slack account.

1. In the desktop app, open Integrations → Slack. If you're a boxes.dev team admin, choose Connect and approve the intended Slack workspace. Otherwise, ask a team admin to connect it. A Slack admin may also need to approve the installation. When you first set up the desktop app, you can also connect Slack on the Connect your accounts page.
2. Back in boxes.dev, choose Link your account if prompted. You can also choose Find my Slack account under Slack identity in Account, or send connect in a one-to-one DM to the boxes.dev Slack app.

If your Slack profile uses a different email from your boxes.dev account, you'll sign in with Slack, and boxes.dev will link the account you sign in with. Verify your boxes.dev email first if you haven't yet.

You can also start from Slack: choose Add to Slack on the boxes.dev for Slack page, approve the workspace, then sign in to boxes.dev (or create an account) and choose Connect. Finish in the same browser where you approved boxes.dev in Slack. Only a boxes.dev team admin can connect the workspace. If you're new to boxes.dev, get the desktop app and set up a project before you turn on Slack requests.

When a new connection finishes, the boxes.dev app will send the person who approved it in Slack a direct message with the steps to get started and links to this guide and support. Reinstalling while the workspace is still connected won't send it again. Teammates who open the app's Messages tab in Slack before it has messaged them will get a short welcome that explains how to link their Slack account and start a request.

Each boxes.dev team connects to one Slack workspace. Send the public installation guide to an administrator who needs instructions for approval.

Activate Slack requests

Your Default behavior is the automation that will handle plain @boxes.dev <request> mentions from you. It belongs to the boxes.dev project where you create it and will use your saved environment, credentials, and usage.

When a new project finishes setting up and you've already linked Slack, the desktop app will show Start threads from Slack above the project, with the coding agent, model, and reasoning level your requests will use. Choose Turn on to activate your Default behavior with those settings, or Configure to review it first and then choose Activate. You can also set it up at any time from Integrations:

1. In Integrations → Slack, choose Create automation.
2. On the paused Default behavior card, choose Configure. Review the prompt, the Codex or Claude Code selection, the model, allowed channels and people, and reply settings, then choose Save changes if you've edited them.
3. Choose Activate.
4. In Slack, add the boxes.dev app to the channel where you'll use it, or open a one-to-one DM with the app. For example, in a Slack thread where your team is discussing an error, you could send:

@boxes.dev investigate the error above and explain the likely cause

The mention will start a fresh devbox from your latest Template box snapshot, or the current saved Team Template version in a managed project. To change the starting environment, update the snapshot or saved version before sending the request. With the default activity settings, Slack will receive a start message with a link to the boxes.dev thread. The thread will also appear in your main thread list. Replies when a run ends can include the agent's full response or a short status and link, as configured below. Agent replies never notify a whole channel: @here, @channel, and @everyone in a reply show as plain text.

To return to Slack from the desktop workbench, select the Slack icon beside the thread title. Its tooltip says Open Slack thread.

The agent receives your saved prompt, your request, and the available messages from the Slack thread. If part of the Slack context can't be read, the run can start with what's available, so supply any missing context or files the agent needs.

Start work with a Slack mention, then follow the agent's progress and replies in the thread. Select the image to enlarge it.

Follow up in the same Slack thread

Mention @boxes.dev again in the Slack thread to send another instruction to the same agent conversation. Replies without the mention won't send an instruction, but the agent can retrieve them when it reads the Slack thread again. boxes.dev tells the agent who sent each follow-up.

If Slack limits a read, the tool tells the agent when to try again and which context may be missing. Reads show the newest available messages and indicate when earlier ones were omitted; they don't synchronize older edits or deletions.

Use these controls in the linked thread:

• @boxes.dev help or @boxes.dev !help to see how to follow up and stop the agent.
• @boxes.dev !stop to request that the active agent turn stop.
• @boxes.dev !cancel to cancel queued Slack follow-ups when possible.

A follow-up may wait while its devbox wakes. Separate Slack conversations can start work in parallel, subject to your awake devbox and billing limits.

Create a named command

Use a named command for a repeatable task with its own saved instructions, such as investigating bugs.

1. In the desktop app, open Automations → New automation and choose Slack.
2. Choose Codex or Claude Code, write the prompt, and set a command name such as bugfix. Names accept lowercase letters, digits, hyphens, and underscores; help, stop, and cancel are reserved.
3. Choose where the command can run and who can use it. Choose Create to save the automation, then Activate to allow Slack requests.

For example, in a Slack thread about a failing check, you could run:

@boxes.dev !bugfix investigate this failure and propose a fix

The text after the command name is your request for that run; the agent receives it alongside the automation's saved prompt and the Slack thread context.

As the automation's owner, you can always run the command. You can also allow selected teammates or any teammate with Slack connected, or choose Me, teammates, and bots to let bots in your Slack workspace run it too.

Let teammates start work in your project

On your Slack Default behavior card, open Configure and find Who else can trigger a new thread?. The default is No one; the setting belongs to you, and teammates can't grant themselves access. Choose specific teammates or any teammate with Slack connected, then choose Save changes.

An allowed teammate can start work in your project with @boxes.dev @YourName <request>. The teammate mention must immediately follow the app mention, and both people need to be active members of the same boxes.dev team with linked Slack accounts.

That task will use your automation, saved environment, credentials, and usage. It won't copy files from anyone's existing devbox. If start messages are enabled, that message will name you as the owner. You'll also receive a DM with links to the request and the new boxes.dev thread, even when automatic activity in the source conversation is off.

An allowed teammate's requests will have the same reach as yours: the agent can use anything your devbox can reach, including your code, credentials, and connected accounts, such as your claude.ai connectors when Claude uses a claude.ai login. Allow only teammates you'd trust with that access, and apply the same care when you let teammates run a named command.

Allowed teammates can also send follow-ups in Slack threads linked to your automation, including threads you started. For each teammate request, boxes.dev tells the agent who sent it and that the work runs in your project with your credentials, and asks the agent to keep your secrets and credentials out of its replies. Their requests appear in the Slack thread for everyone there to read, and in the boxes.dev thread for you.

To start another teammate-owned task in an already linked Slack thread, name the teammate again. Later follow-ups without a teammate's name will go to the newest linked run.

In a private channel, a teammate or an allowed bot can start work in your project only if you're a member of that channel. Slack shows a private channel's name and messages only to its members, and the task would bring both into your boxes.dev thread. If you're not in the channel, boxes.dev won't start the task. When start messages are on, it will reply to a teammate in the Slack thread to explain why, but it won't reply to a bot. To run the task in your project, ask someone in the channel to add you. The teammate can also use an automation of their own.

This also applies after the task starts. If the channel becomes private without you in it, or you leave a private channel, boxes.dev won't pass teammates' or bots' follow-ups in that Slack thread on to your task, and your agent won't be able to read the thread.

Any task that starts from a private channel, including your own, will run in a private boxes.dev thread. Your teammates won't be able to browse or read it in boxes.dev under any Thread access setting until you share it, and sharing it will apply your team's setting again. boxes.dev decides this when the task starts, so a thread started while its channel was public keeps your team's setting if the channel becomes private later.

Let bots start work in your project

Some teams want another Slack app to start work, such as a bot that posts new signups or failing alerts. To allow that, choose Me, teammates, and bots for a named command, or Teammates and bots under Who else can trigger a new thread? for your default behavior, then choose Save changes. Bots that belong to another organization in a Slack Connect channel will still be ignored, and boxes.dev never responds to its own messages.

Because a bot doesn't have a boxes.dev account, its message needs to name you. For a named command, the bot needs to use the full command with your name, which the automation editor shows in its example. For instance, a signup bot could post this to run Ananya's onboarding command:

@boxes.dev !ananya/onboarding New signup: sam@example.com

For your default behavior, the bot needs to mention you right after @boxes.dev, as a teammate would: @boxes.dev @YourName <request>. A bot message without your name won't start anything, and boxes.dev won't reply to it. If the bot posts through the Slack API, write each mention as <@MEMBER_ID>, using the Slack member ID of the boxes.dev app or your own.

Work a bot starts will run in your project with your credentials and usage, just like a teammate's request. Start messages and final replies will follow your activity settings, but you won't get the DM that a teammate's request sends. boxes.dev tells the agent that a bot sent the request and that text in bot messages can come from people outside your team. Anyone who can make an allowed bot post, for example by filling in a form the bot relays to Slack, can send requests with your access, so allow bots only on automations you're comfortable exposing that way. Allowed bots can also send follow-ups in the linked Slack thread, but boxes.dev never imports files that bots post.

Choose channels and reply visibility

Slack automations initially allow internal channels where the app is available, plus one-to-one app DMs, so running in a channel shared with another organization is always a choice you make. To allow requests from a shared Slack Connect channel, open the automation editor and select Everywhere boxes.dev is available, including Slack Connect, or choose the channel under Only selected channels. Shared channels are marked External in the picker.

External Slack users and guests cannot start work or send follow-ups. Group DMs are unsupported.

Under What should boxes.dev post in the Slack thread?, choose reactions, start messages, attachment warnings, follow-up confirmations, and replies when a run ends. The Internal and Slack Connect columns control each audience separately. For a quiet customer channel, choose None above Slack Connect; use All or individual checkboxes to turn activity back on. Choose Save changes when finished.

Choose which activity appears in internal Slack conversations and shared Slack Connect channels. Select the image to enlarge it.

With replies enabled, leave Include the full agent response off for a short status and link. Turn it on only when that audience should receive the agent's response and failure text. It starts off for Slack Connect. Attachment warnings can stay on even when start messages and follow-up confirmations are off.

Turn on Messages the agent is asked to post to let the agent post extra messages in the Slack thread when a request or the automation's instructions ask for it, such as progress updates during long work. It starts off for both audiences. boxes.dev posts automatic replies only for work that starts from Slack, so this is how an agent that keeps working later, for example after a message from another agent, can report back in the thread. The agent won't use it to repeat a final reply that boxes.dev already posts.

The location menu decides where requests can start; the activity controls decide what boxes.dev posts there. The Slack Connect column appears when your location choice allows shared channels. Hiding that column, or turning off replies, will preserve its saved choices for later.

Changes will apply to new Slack threads. Existing linked threads keep the settings they started with, except for agent messages: turning those off will also stop agents in existing threads from posting. These controls cover the automation's automatic activity; help and responses before an automation is identified are separate. Turning activity off will not redirect those messages to DMs.

Include Slack files

The agent can receive Slack-hosted, downloadable attachments up to 100 MB each. Your own eligible files are always allowed. The setting Allow files from other Slack workspace members also permits files from verified ordinary internal members of your workspace, even if they can't run the automation. New automations have this setting on; older automations keep their existing choice.

When a file comes from an external Slack user, including someone in Slack Connect or a guest, boxes.dev will ask the person who triggered the request to choose Upload file or Skip. Only that person will see the approval message. Only upload files you trust, since they may contain malware or malicious instructions.

The agent will start with the available text and files. Upload file will send the approved file to the same agent thread as a follow-up, while Skip will leave it out. Each approval applies only to that file and request. Private approval prompts will appear even if public attachment warnings are off. The uploaded file and agent replies will follow the thread's existing visibility rules.

Slack's private prompts may disappear when you reload or may not arrive while you are inactive. If you miss a prompt, attach the file in boxes.dev. Approval cannot bypass Slack's file permissions or the 100 MB limit.

Files from bots, deleted users, and unverifiable uploaders are omitted, as are restricted, deleted, unsupported, oversized, or failed downloads. An omitted file won't stop the request: boxes.dev will continue with the files that succeeded and tell the agent which files weren't delivered. It will also explain the omission in Slack when attachment warnings are enabled. Attach an essential missing file directly in the boxes.dev thread.

To change file permissions, open the automation's editor; for default mentions, that's Configure on Default behavior.

Preview shared conversations in Slack

When you post a share link in Slack, boxes.dev will add a preview to your message. The preview shows the conversation's title and the agent's latest reply. Until the agent has replied, it shows your first message instead. Below that, a line with the boxes.dev logo shows the project, the conversation's status (such as Working or Done), and when the last message was sent. Until the conversation has a title, the preview will say boxes.dev thread. Select the title or Open in boxes.dev to open the conversation.

Everyone who can see your Slack message will see the same preview, including guests in your workspace. Posted previews will update on their own as the agent works and replies, and when you rename the conversation.

If you revoke the share, make the conversation private, or delete it, posted previews will change to This shared thread isn't available. A link to another team's conversation shows the same message. Previews also appear in DMs and in private channels the app hasn't been added to. boxes.dev doesn't add previews in channels or DMs shared with another organization.

If your team connected Slack before previews were available, a team admin needs to reinstall the app to turn them on. Until then, mentions, DMs, and automations will keep working, and Integrations → Slack in the desktop app will show Update available. To reinstall, choose Reinstall there and approve the request in Slack. Team admins can also choose Reinstall Slack from the Slack section's actions menu in Team settings.

Recover a connection or trigger

To see what you can start in a conversation, mention @boxes.dev help there, or send help in your DM with the app. boxes.dev will reply with whether your Default behavior can run there, the named commands you can use, and links to this guide and support. If your Slack account isn't linked yet, the app will answer any message from you, including help, with a DM that has a link to connect your account and the next steps.

If a request doesn't start, open Integrations → Slack and follow any connection or setup message shown there. Confirm that your team is connected, your Slack identity is linked, your automation is active, and its channel and people settings allow the request. Use Find my Slack account in the automation editor or send connect to the app if your identity needs linking.

If a channel is missing, add the app to it and choose Check under Team connection. Team admins can also inspect connected users, channels, and permissions there or in Team settings. A private channel's name appears only to people whose linked Slack account is in that channel; everyone else sees Private channel, and channel pickers leave it out. Slack email addresses appear only to team admins and to the person each address belongs to. If only some parallel requests start, check awake devbox capacity and billing.

Understand Slack access and disconnection

In a Slack-triggered run, the agent can read the source Slack thread and direct Slack links you provide. It cannot browse your workspace. It can post only to the source Slack thread, and only when Messages the agent is asked to post is on for that conversation; boxes.dev posts the other enabled activity itself.

Disconnecting Slack will stop Slack triggers, automation posts, and agent access to Slack for the team. Data stored for the Slack connection will be deleted within 14 business days. Uninstalling the boxes.dev app from your Slack workspace will do the same.

Your boxes.dev threads and saved automation settings will remain. See the privacy policy for retention details and how to request deletion.

Manual, scheduled, and API automations can also send results to Slack without starting from a Slack message; see Send results to Slack.