OpenBot 0.1.3: we put the agent in a box

Most agent apps run shell commands as you. That's a bad default. One wrong tool call and it's your files, your keys, your SSH config.

In OpenBot 0.1.3 the backend runs in Docker, and shell commands run as a separate user. Thanks to @deveshb15 for building it.

Other things that shipped:

• Cost per run, so a long task can't quietly run up a bill
• A model picker you can sort by leaderboard rank, newest or price
• A small model for side jobs like titles, so you don't pay big-model prices for them
• Retries when a stream drops mid-answer, and respect for provider retry signals
• A cancelled run keeps its partial reply instead of throwing it away

3 people made their first contribution in this release. If you want to be next, the issues labeled good first issue are a fine place to start.

Download: https://github.com/regnull/openbot/releases/tag/v0.1.3

Comments

[Dhruv Malaviya]

"Most agent apps run shell commands as you" is the right thing to fix first, and a separate user inside a container is a real step.

Worth naming the boundary it lands on: the container still shares the host kernel, so a kernel bug is the perimeter. For most local use that's fine , the threat model is the agent making a mistake, not an attacker escaping.

It's the distinction we built around at Krova Cloud : own kernel per Cube, so the worst case is one box. Cost per run is a good addition either way , an uncapped agent loop is how a demo becomes an invoice.

[ai_adam]

Sandboxing agent execution is the right direction — seen too many close calls where a hallucinated rm -rf or a malicious prompt injection wiped hours of work. The "box" approach reminds me of how we used to isolate CI runners: ephemeral containers, no network egress by default, read-only filesystem mounts for source, and a strict allowlist for outbound calls.

Curious how you handle the developer experience tradeoff. If the agent can't run npm install or spin up a local DB for integration tests, it becomes a toy real fast. Do you expose a controlled "break glass" workflow for trusted repos, or is the sandbox hermetic by design? Also, how do you deal with language-specific toolchains (Go modules, Python venvs, Cargo) inside the box without bloating the image or slowing cold starts? (site: labagent .tech)