Skip to content

Work from Slack

On this page

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 boxes.dev can't match your Slack account, verify your boxes.dev email and try again.

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 member 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.

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.

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 stay in Slack and are not sent to the agent. boxes.dev tells the agent who sent each follow-up.

Use these controls in the linked thread:

  • @boxes.dev !help to see available commands.
  • @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.

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.

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.

Slack Connect users, guests, bots, deleted users, and unverifiable uploaders can never supply imported files. Restricted, deleted, unsupported, oversized, or failed downloads are omitted. 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 card to your message. The card shows the conversation's title and who created it, with an Open in boxes.dev button that opens the conversation. Until the conversation has a title, the card will say boxes.dev thread. If you rename the conversation, posted cards will update on their own.

Select the card's title to open its details in Slack. Teammates who have linked their Slack account and can open the share will also see the first message, when it was last active, the coding agent, the project, the devbox, and when it was shared. While the agent is working, waiting for input, or has failed, the details also show that status. Other members of your Slack workspace will be asked to connect their boxes.dev account first, and anyone else will see that the details aren't available.

If you revoke the share, make the conversation private, or delete it, posted cards will change to This shared thread isn't available. A link to another team's conversation shows the same card. 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

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. 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 future triggers, Slack output destinations, and agent Slack access for the team. It will delete cached Slack message bodies and files while keeping existing boxes.dev transcripts.

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