sandboxed.sh
Self-hosted mission-execution backend for autonomous AI agents: isolated Linux workspaces, Git-backed skill Library, and MCP-driven orchestration.
- Source repo
- Th0rgal/orb
- Stars
- ★ 534
- Last updated
- today
- Primary language
- Rust
- FA score
- 52/100 · Major gaps
At a glance
- How it runs
- Works with
- Universal · cross-platformCodex · Claude Code
- Cost
- Free software; you pay for model usage
- Setup effort
- Medium · a few setup steps
- You'll need
- Typical use
- Hand off entire dev cycles: point an agent at a GitHub issue, let it write code, test, and open a PR when tests pass.
- Not a fit if
- Users wanting a standalone tool: it needs an MCP coordinator to be useful
- Teams deploying natively on anything other than Ubuntu 24.04
- Those unwilling to grant privileged: true or run pre-release software
- Source review
- 52/100 · Major gaps
What does this agent do, and when should you use it?
sandboxed.sh (formerly Open Agent) is a self-hosted mission-execution backend for autonomous AI agents, running coding agents inside isolated Linux workspaces (systemd-nspawn or Docker containers). It pairs with a coordinator such as the Hermes fork hermes-agent, which decides what to run over MCP while sandboxed.sh executes the missions. It supports Claude Code, OpenCode, Codex, Gemini, and Grok runtimes, managing projects, controller crons, and missions with structured state via MCP tools. A Next.js web dashboard and a SwiftUI iOS app provide real-time monitoring, a Git-backed Library of skills, tools, rules, agents, and MCPs, plus cron-like automations. Deployment is via Docker (~5 minutes) or native on Ubuntu 24.04 (~30 minutes). The project is under active development and MIT-licensed.
Receives missions over MCP from a coordinator (e.g. hermes-agent) via tools like start_mission, launches agent runtimes (Claude Code, OpenCode, Codex, Gemini, Grok) inside isolated workspaces using systemd-nspawn or Docker, streams results back, and maintains project records in projects.db with structured MCP tools (list_projects, update_project_status, set_project_grant, link_mission_to_project). It supports model routing with provider fallback chains and health checks, an OpenAI-compatible proxy queue mode, and native inference protocols (Chat Completions, Responses, Anthropic Messages).
- Hand off entire dev cycles: point an agent at a GitHub issue, let it write code, test, and open a PR when tests pass.
- Run multi-day unattended operations: set up model fine-tuning in an isolated sandbox.
- Keep sensitive data local: perform local inference in isolated containers without sending data to external services.
- Manage multiple long-running projects with structured autonomy grants and scheduled controllers.
- Monitor missions remotely with real-time streaming and system metrics via the dashboard.
How do you install or deploy this agent?
Docker (recommended): git clone https://github.com/Th0rgal/sandboxed.sh.git && cd sandboxed.sh && cp .env.example .env (edit settings) && docker compose up -d, then open http://localhost:3000. For container workspace isolation, uncomment privileged: true in docker-compose.yml. Native (Ubuntu 24.04): follow the guide; requires git pull + cargo build.
How do you use this agent?
After installation, follow the Getting Started Guide to configure your backend connection, set up your library repository, and create your first mission. Connect an MCP-capable coordinator such as hermes-agent or any MCP assistant to drive missions via MCP tools. Use the web dashboard or iOS app to start, stop, and monitor missions; manage skills and MCP servers from the Git-backed Library.
What are this agent's strengths and limitations?
- True container isolation via systemd-nspawn/Docker, scoping agent operations.
- Multi-runtime support: Claude Code, OpenCode, Codex, Gemini, and Grok on the same infrastructure.
- MCP-native: any MCP-capable assistant can act as the coordinator; Hermes is the reference implementation.
- Git-backed Library for versioning skills, tools, rules, and agents.
- Structured project state (grants, tracks, decisions) instead of free-text status.
- Requires a coordinator (MCP client) to be useful; sandboxed.sh is one half of a two-part system.
- Native install is Ubuntu 24.04 only; Docker path requires privileged: true for container isolation.
- Project is under active development (Work in Progress) and may be unstable.
- Orchestration architecture (control plane, missions, controllers) adds a learning curve.
- License is listed as MIT; no other compliance guarantees documented.
How does this agent compare with similar options?
The source names Hermes (hermes-agent) as the reference coordinator but explicitly states any MCP-capable assistant can fill that role.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| sandboxed.sh This agent | 52 · Major gaps | Self-hosted serviceFree + model costs | ★ 534 | today | Rust | Codex · Claude Code |
| Cezar — AI Coding Agent Orchestrator | 63 · Some gaps | CLIFree | ★ 796 | 1d ago | TypeScript | Codex · Claude Code |
| Vicoa | 52 · Major gaps | Desktop appFree + model costs | ★ 519 | 12d ago | Python | Codex · Claude Code |
| Solo Agent | 48 · Major gaps | Self-hosted serviceFree + model costs | ★ 594 | 1mo ago | Go | Codex · Claude Code |
How does FollowAgents rate this agent?
Why each dimension lost points
Least privilege: README recommends enabling privileged: true for Docker container workspaces, which substantially abandons container isolation — heavy deduction despite systemd-nspawn design. User confirmation: missions can open PRs, SSH into home GPUs, and run unattended for days with no visible mandatory human-confirmation gate. Data flow transparency: architecture diagram and control-plane doc give a fairly clear project/mission/receipt/evidence model (2). Sensitive data: Cargo.toml shows AES-GCM/PBKDF2 and README emphasizes local inference and isolation, but the crypto implementation is not visible in the sample (2). Dependency security: conventional version ranges, no lockfile/audit strategy evidence (2). External effects: large blast radius (PRs, SSH) partially mitigated by the autonomy-grant concept. Rollback: only a zip backup/restore dependency hints at recovery; no explicit rollback flow (1). Source attribution: 'sandboxed.sh Contributors', unverified publisher, though the upstream fork relationship is documented via FORK.md (1).
Self-consistency: README and Cargo.toml align (v1.3.0, MCP binaries, Hermes coordinator), no contradictions (2). Dependency availability: mainstream maintained deps, but rust-version 1.91 conflicts with the in-file MSRV 1.75 comment (deduction). Failure messages: tests rely on waitForTimeout and broad catch-and-ignore; no evidence of structured error messaging documentation (1).
Audience and scenarios: self-hosted dev automation scenarios (hand off dev cycles, GPU training, local data analysis) are concrete (2). Capability boundaries: clear coordinator/sandbox split and rules for when to dispatch missions vs. in-conversation subagents (2). Trigger precision: controller cron triggering is described only conceptually, no config examples in sample (1). Environment fit: dual Docker/native paths with Xvfb/X11 desktop automation notes (2).
Information architecture: excellent README organization with a full docs index (3). Install notes: dual install guides exist, but the ordering that defaults Docker to non-privileged while recommending uncommenting privileged is a worrying footgun. Naming stability: renamed from 'Open Agent'; residual naming risk (1). Examples/FAQ: no FAQ; examples limited to install commands (1). Known limitations: 'Work in Progress' stated (2). License: README declares MIT but no LICENSE file appears in the sample and metadata is 'unknown' (2). Versioning/changelog: version 1.3.0 present, no CHANGELOG; release notes auto-generated (1). Maintenance responsibility: 'active development' without named maintainers or update path (1).
Output usability: structured receipts/evidence and SSE streaming with consistent roster across web/desktop/iOS (2). Marginal value: genuine differentiation combining multi-runtime sandboxed orchestration with a project control plane, but ecosystem coupling to a self-maintained Hermes fork (deduction, 2). Cost-benefit: deployment cost (privileged Docker, Ubuntu 24.04) vs. autonomy benefit is unquantified; only setup-time estimates given (1).
Claim traceability: README claims (isolation, encryption, health-check routing) cite docs not verifiable in the provided sample (1). Cross-source corroboration: CI workflows and dashboard tests partially corroborate README features, but core security claims cannot be cross-verified from these files (1). Fact/inference separation: vision section is clearly framed as aspiration; 'Work in Progress' is distinct from the feature list (2).
- Docker deployment recommends enabling privileged: true, which effectively negates container isolation — a high-risk default in an autonomous-agent context; evaluate rootless containers or native systemd-nspawn before deploying.
- Autonomous missions can open PRs and SSH into remote hosts; no mandatory human-confirmation gate is visible in the sample. Verify the actual implementation and defaults of autonomy grants/budgets before use.
- MIT license is declared only in the README; no LICENSE file appears in the sample — confirm legally before adoption.
- No CHANGELOG or explicit maintainer commitment found; the project self-describes as Work in Progress and APIs may change frequently.
- Static review with low confidence: security claims (isolation, encryption) come from documentation and were not execution-verified.
Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
v0.12.0 v0.12.0 — Grok Build, Needs You, iOS UX
Release notes excerpt
v0.12.0 — Grok Build, Needs You, transcript streaming, iOS UX Grok Build — first-class backend - Full xAI OAuth flow (device-auth), ~/.grok/auth.json mirrored per mission workspace, container-aware --cwd translation, grok-build default model exposed via /api/providers. - /goal <objective> for Grok. Grok ships no native goal mode, so sandboxed.sh drives the loop: a sentinel protocol (<goal_complete/> / <goal_continue/> / <goal_aborted reason="…"/>) is injected into the first-turn prompt, then an AgentFinished automation re-fires a short continuation prompt every tu …View on GitHub ↗ -
v0.11.5 v0.11.5 - Native Harness Loops & iOS Network Resilience
Release notes excerpt
Bundles PR #432 — clean reimplementation of the still-unique work from the abandoned #430 (Codex goal mode + iOS network resilience WIP). Features Native harness loops as Automation rows Claudecode and codex /goal continuation loops now materialize as first-class rows in the Automations panel, with iteration badges and a per-row stop button — alongside OA-scheduled automations. - New NativeLoopAdapter trait + registry in src/backend/native_loops.rs …View on GitHub ↗ -
v0.11.1 v0.11.1 - Mission Workbench BugBot Fixes
Release notes excerpt
v0.11.1 highlights Patch release for the Mission Workbench and Needs You inbox rollout. Changes - Aligns Mission Workbench running-state rendering with the header's effective running-state logic instead of treating any RunningMissionInfo object as running. - Keeps running missions indigo in the workbench, while stale/finished running records fall back to the stored mission status. - Preserves the Needs You inbox total-count fix from v0.11.0 and the workbench running-color fix from PR #404. - Bumps backend and dashboard package versions to 0.11.1. Verification …View on GitHub ↗