Skip to main content
Slack Agent uses a shared workspace sandbox for code execution, not a private environment per user. Saved state, installed packages, and snapshots benefit the entire team. Configuration changes affect every run in the workspace, so coordinate with your team before making changes.

How sandboxes work

Each Slack thread maps 1:1 to a sandbox instance with its own git worktree branch and snapshot chain. Slack Agent restores from the most recent snapshot when a thread starts work and snapshots the sandbox when a run completes. The shared base snapshot provides the starting point for all new threads.

Guaranteed tools

Every sandbox includes:
CategoryTools
Version controlgit
Network and archivecurl, tar, zip, unzip
Languagespython3
Search and navigationrg (ripgrep), fd, tree
Data processingjq, yq, sqlite3, gawk
Build and patchmake, patch, file
Systemtime, procps
Optional: gh (GitHub CLI), glab (GitLab CLI) on a best-effort basis.

What admins can configure

  • Runtime selection (curated set including modern Node.js and Python, not arbitrary environments)
  • Package setup
  • Saved snapshots
  • Reset-to-clean behavior
  • Interactive editing or console access where supported

Lifecycle states

StatusMeaning
draftConfiguration exists, no snapshot saved yet
savingSnapshot save in progress
readySaved snapshot available
failedMost recent operation failed
archivedSandbox retired

What’s next

Admin roles and security

Confirm who should be allowed to manage shared workspace execution settings.

Working in Slack

Understand when Slack Agent might rely on the shared sandbox during real conversations.

Thread reviews

Inspect the resulting runs and diffs after sandbox-backed work completes.