sbx (Docker Sandboxes) microVM on your host, and you drive it from a
Discord channel and thread: start a session from your phone, watch it work, and
pick it back up later.
The model is small enough to hold in your head:
- Channel = project. One
sbxsandbox and one host directory. - Thread = session. One OpenCode conversation.
- The bot runs on the
sbxhost (Windows 11 for v1), because only the host can invoke thesbxCLI. It supervises one long-livedsbx exec ... opencode servechild per project and talks to it over the sandbox’s published loopback port using the@opencode-ai/sdk.
celly-<slug>), the default Discord category is Forge, and the theme is
generic smithing folklore rather than any trademarked name.
Topology
sbx secret at the host proxy. They are
never stored in the bot or the repository.
Celly is a deliberately lightweight re-implementation of the command surface of
remorses/kimaki (MIT), with sbx
sandboxes replacing Kimaki’s local process management.
Start here
Quickstart
Bootstrap the host, install Celly, and run your first prompt in a few
minutes.
Commands
The full v1 command surface, access rules, and what is deferred.
What you get in v1
- Per-project sandbox isolation. Every project owns a microVM; the host filesystem outside the mounted project directory is unreachable by the agent.
- Streaming replies. Assistant text and tool activity stream into the thread and are throttled into a single live message.
- Session resume.
/resumereopens a past OpenCode session in a new thread. - Model and agent switching.
/modeland/agentpick per-thread settings. - Abort.
/abortstops the current run (in a thread) or every active run in the project channel. - Shell. A message starting with
!runsbash -lc <command>inside the project’s sandbox and posts the output. - Terminal coexistence. Sessions are shared between Discord and a terminal attached to the same sandbox.