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.
- 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.
- Back in boxes.dev, choose Link your account if prompted. You can also
link by sending
connectin 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:
- In Integrations → Slack, choose Create automation.
- 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.
- Choose Activate.
- 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.
Use these controls in the linked thread:
@boxes.dev !helpto see available commands.@boxes.dev !stopto request that the active agent turn stop.@boxes.dev !cancelto 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.
- In the desktop app, open Automations → New automation and choose Slack.
- 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, andcancelare reserved. - 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.
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.
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.
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.
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. 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.
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 or send messages through that access; the integration posts enabled replies separately.
Disconnecting Slack will stop future triggers, Slack output destinations, and agent Slack read 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. For a shared support channel with the boxes.dev team, see Contact support.