Minusbot: The AI Agent That Never Sees Your Secrets
A Bun-powered, Docker-isolated assistant platform that runs across Discord, Telegram, and the web while proxying sensitive credentials outside the model's view.
- Minusbot's real innovation is a trust boundary, not a louder chatbot, because the model reasons while the runtime and vault handle execution.
- Discord, Telegram, and the web are front doors to one shared agent core, which makes the project feel like a platform instead of three separate bots.
- Dockerized skills let Minusbot treat Bash, Git, FFmpeg, and similar capabilities as replaceable modules instead of host-level dependencies.
- The repo competes less with generic chatbots than with the unsafe default way teams wire agents together.
The interesting part of Minusbot is not that it can talk in three places. It is that the same agent can do real work without being handed raw credentials. The repo, minusbot-org/minusbot, treats an LLM as the planner, Docker as the body, and a vault as the only place where secrets actually live.
Stop sharing raw API keys with LLMs. Secret Proxying: Skills use keys stored in encrypted vaults. Zero-Exposure: The LLM interacts with skills handles, never seeing the raw secrets.
The dangerous part of agents is execution
Most agent demos are easy to admire and hard to trust. The handoff from language to action is where things break, because that is the moment a prompt stops being text and becomes a command with side effects. Minusbot is built around that seam.
The codebase reflects that split. Messages enter through an input processor, which routes commands one way and agent prompts another. The agent then builds context, calls tools in a loop, and returns only after the runtime has done the work that the model itself should never touch directly.
How Minusbot keeps the model out of the room
That separation is the point of the project. The agent can request a tool, but the tool runs in a sandboxed container, and the vault injects secrets only for that execution window. The model sees intent, not raw credentials.
That is also why the runtime details matter. The sandbox captures container output, streams it back, and keeps the host from becoming the place where every risky capability gets installed permanently. Minusbot is not pretending execution is harmless. It is making execution containable.
A bot that lives in three places at once
The multi-channel part is not a garnish. Minusbot uses one system for Discord, Telegram, and the web, so shared state, file delivery, and action routing stay consistent no matter where the request began. That is how a bot starts to feel like a platform.
The web dashboard matters for the same reason. It turns the agent into something observable, with telemetry around usage and efficiency instead of a black box that only speaks when summoned. In practice, that is often what separates a toy assistant from a system people can rely on.
Why Bun and TypeScript are not incidental
Bun is part of the story because this repo wants fast I/O, quick startup, and TypeScript-native ergonomics in the same package. That matters when the app is juggling agent loops, channel adapters, sandbox runs, and live updates at once.
TypeScript gives the boundaries shape. The repo separates AI provider logic, channel bridges, sandbox execution, tools, data, and web UI into distinct areas, which makes the architecture legible instead of sprawling. This is the kind of codebase where the stack choice supports the product thesis rather than decorating it.
The skills layer is where the project gets interesting
Minusbot draws a sharp line between native tools and skills. Tools are the lighter-weight calls inside the app. Skills are heavier capabilities, often wrapped in their own containers, so Bash, Git, FFmpeg, SSH, and similar tasks can run without polluting the rest of the system.
That distinction is easy to miss, but it is one of the most practical design choices in the repo. It means the agent can do serious work without the host environment turning into a permanent pile of special cases.
What Minusbot is really competing with
| Project type | Execution model | Secret handling | Channel coverage | Best use case |
|---|---|---|---|---|
| Minusbot | LLM planner plus Dockerized execution layer | Secrets are proxied at runtime and kept out of the model's view | Discord, Telegram, web | Secure multi-channel assistants that can act on real systems |
| LangChain or OpenHands style frameworks | Composable agent scaffolding that you wire into your own app | Usually handled by the host application | Whatever you integrate | Teams that want building blocks, not an opinionated product |
| Moltbot | High-autonomy, local-first agent system | Security depends on how the local environment is set up | Messaging gateways and broader computer use | Users who want broad agent autonomy |
| Traditional bot | Scripted handlers and fixed commands | Often direct environment variables or config files | Usually one primary channel | Deterministic automation with limited scope |
The table makes the positioning plain. Minusbot is not trying to win by being the broadest framework or the most autonomous computer-using agent. It is trying to be the safer middle layer where a model can plan, a sandbox can execute, and a channel can deliver the result.
The shape of a practical AI operating system
Minusbot is interesting because it treats trust as an architecture problem, not a policy problem. That is the difference between a clever assistant and a system that can survive real use. The model gets judgment, the runtime gets control, and the vault keeps its distance.
That is the larger lesson here. As agents move from suggestion to action, the important question is no longer whether the model can do more. It is whether the system knows exactly where the model ends.
