sandboxed.sh — Summary

sandboxed.sh (formerly Open Agent) is a self-hosted cloud orchestrator for AI coding agents — a Rust backend + Next.js dashboard that provisions isolated Linux workspaces using systemd-nspawn containers and runs multiple agent runtimes (Claude Code, OpenCode, Codex, Gemini, Grok) inside them. Each "mission" gets a per-mission workspace directory and a dedicated harness process that streams JSON events back to the dashboard; the backend handles orchestration, workspace isolation, Library-based configuration management, provider health checks, and rate-limit fallback chains. The "Library" is a Git-backed repository of skills, tools, rules, agents, and MCPs that gets synced into each workspace's agent config files (.claude/skills/, CLAUDE.md, .opencode/, etc.) at mission start. It ships two orchestrator Claude Code skills (orchestrator-boss and orchestrator-worker) that implement a hierarchical parallel work delegation pattern with worktrees and state JSON recovery. sandboxed.sh also ships an iOS app (SwiftUI with Picture-in-Picture) and integrates with Telegram for chat-based mission creation.

Differs from seeds: sandboxed.sh is architecturally closest to agent-os (seed, bash-script-bundle) in that both provide a scaffold for wiring multiple agents together with shared configuration. But sandboxed.sh is far more operational: it has a running Rust server, a Next.js dashboard, systemd-nspawn workspace isolation, provider fallback chains, and live streaming — while agent-os is just bash scripts and markdown. The orchestrator-boss/worker skills echo claude-flow's hive-mind worker pattern but are implemented as Claude Code skill files (persona-md style) rather than code classes.

Note: sandboxed-sh and open-agent-thorgal point to the same GitHub repository (Th0rgal/openagent), which self-describes as "formerly known as Open Agent". The canonical slug for this analysis is sandboxed-sh; open-agent-thorgal is marked non-canonical.

sandboxed.sh — Overview

Origin

Originally named "Open Agent", the project was renamed to "sandboxed.sh" (Formerly known as Open Agent — stated in the README). It was built by Th0rgal and grew from a vision of fully autonomous multi-day agent operations:

Vision (verbatim from README)

"What if you could:"

"Hand off entire dev cycles. Point an agent at a GitHub issue, let it write code, test by launching desktop applications, and open a PR when tests pass. You review the diff, not the process."

"Run multi-day operations unattended. Give an agent SSH access to your home GPU through a VPN. It reads Nvidia docs, sets up training, fine-tunes models while you sleep."

"Keep sensitive data local. Analyze your sequenced DNA against scientific literature. Local inference, isolated containers, nothing leaves your machines."

Core philosophy

The project treats the AI coding agent runtime as a commodity that should be swappable — the same orchestration infrastructure runs Claude Code, OpenCode, Codex, Gemini, or Grok. The value is in the orchestration layer: workspace isolation, Library sync, mission streaming, provider fallback, and the multi-agent boss/worker pattern.

The README's "Build X-Agent Hackathon" section (targeting OKX security) reveals another design principle: skills become operational infrastructure — a Library item synced into every agent environment rather than a one-off prompt.

On-chain / security agent use case

The repo's top-level text (for a hackathon) highlights using sandboxed.sh for on-chain AI agents: running OKX security skills unattended inside isolated workspaces so the agent can inspect token/DApp/transaction risk without exposing host files or wallet secrets.

Architecture philosophy

From agents.md (verbatim):

"The core change: agent harnesses run inside the target workspace, so native bash and file effects are scoped to the correct environment. The host proxy bash tools are no longer required for normal missions."

This reflects a deliberate move from a host-proxy architecture to a per-workspace harness architecture — each agent runs inside its workspace container, making bash commands and file operations naturally scoped.

sandboxed.sh — Architecture

Sandbox primitive

systemd-nspawn containers (native Ubuntu 24.04 bare-metal) or Docker containers (with privileged: true for nested nspawn). NOT microVM.

• Each mission gets an isolated Linux workspace via systemd-nspawn
• The agent harness runs inside the workspace, so native bash and file operations are container-scoped
• Desktop automation: X11/Xvfb for headless GUI applications

Distribution

• Self-hosted via git clone + docker compose up or native Ubuntu install
• Docker (recommended): docker compose up -d → http://localhost:3000
• Native (Ubuntu 24.04): cargo build + bun install

Install

git clone https://github.com/Th0rgal/sandboxed.sh.git
cd sandboxed.sh
cp .env.example .env
docker compose up -d

Directory tree (repo)

sandboxed.sh/
├── backend/              # Rust server (Axum or similar)
├── dashboard/            # Next.js web dashboard (port 3000)
├── skills/
│   ├── orchestrator-boss/SKILL.md
│   └── orchestrator-worker/SKILL.md
├── .claude/
│   ├── CLAUDE.md         # Claude Code context for repo development
│   └── settings.json     # Claude Code permissions
├── agents.md             # Harness architecture documentation
├── docs/
│   ├── HARNESS_SYSTEM.md
│   ├── WORKSPACES.md
│   ├── MISSION_API.md
│   ├── WORKSPACE_API.md
│   ├── BACKEND_API.md
│   ├── install-docker.md
│   ├── install-native.md
│   └── getting-started.md
├── android_dashboard/    # Android companion app
├── ios_dashboard/        # iOS companion app (SwiftUI)
├── shared/               # Shared Rust/TS types
├── docker-compose.yml
├── Dockerfile
├── Cargo.toml            # Rust workspace
└── capabilities/         # Agent capability definitions

Required runtime

• Docker (recommended) or Ubuntu 24.04 LTS (native)
• Rust (for native build)
• Bun (for dashboard)
• systemd-nspawn (for container workspace isolation, native path)
• Xvfb (for desktop automation, headless)

Harnesses supported

Library system

A Git-backed repository of skills, tools, rules, agents, and MCPs. At mission start, Library content is synced into each workspace's agent config files. This ensures all agents see the same Library items regardless of which harness they use.

Host-OS posture

Moderate — Docker requires privileged: true for nested systemd-nspawn. Native install uses systemd-nspawn directly. The agent runs inside the container, but container escape is a real risk with privileged mode.

Config files

• .env (API keys, configuration)
• docker-compose.yml
• Library repo (external git repo pointed to by dashboard settings)

sandboxed.sh — Components

Backend services

Claude Code skills (shipped in repo)

These are persona-md format skill files with YAML frontmatter.

Library system components

Library items (synced from a Git repo into each workspace):

• Skills — Claude Code / OpenCode / Codex skill files
• Tools — MCP server configs or custom tool definitions
• Rules — behavior rules injected into agent context
• Agents — agent configurations
• MCPs — MCP server entries

Harness system

The harness system writes per-workspace config files at mission start:

• CLAUDE.md — workspace-level context for Claude Code
• .claude/settings.local.json — MCP servers + permissions for Claude Code
• .claude/skills/<name>/SKILL.md — skills synced from Library
• opencode.json — OpenCode configuration
• .codex/config.toml — Codex configuration

Mission API

Per docs/MISSION_API.md:

• Create, start, stop, monitor missions
• Real-time streaming of JSON events from harness
• Worker mission creation (for orchestrator-boss pattern)

MCP Registry (optional)

Extra MCP tool servers available when needed: desktop automation, Playwright, etc.

OpenAI-compatible proxy (optional)

Queue mode for deferred execution via /v1/chat/completions when all providers are temporarily rate-limited.

Provider routing

Model routing with:

• Provider fallback chains (health checks + rate-limit handling)
• Supports: Claude Code backends, OpenCode backends, Codex, Gemini, Grok

Automations

Cron-like triggers for scheduling recurring agent runs.

Telegram integration

Connect bots to missions for chat-based AI assistants with auto-mission creation per Telegram chat.

.claude/settings.json (repo development permissions)

{
  "permissions": {
    "allow": [
      "Bash(cargo build:*)", "Bash(cargo run:*)", "Bash(cargo test:*)",
      "Bash(cargo fmt:*)", "Bash(cargo clippy:*)", "Bash(bun:*)",
      "Bash(cd dashboard && bun:*)", "Bash(git:*)", "Bash(ls:*)",
      "Bash(cat:*)", "Bash(mkdir:*)", "Bash(rm:*)", "Bash(cp:*)",
      "Bash(mv:*)", "Bash(jq:*)", "Bash(ssh:*)", "Bash(scp:*)",
      "Bash(python:*)", "Bash(curl:*)", "Read", "Write", "Edit", "Glob", "Grep"
    ],
    "deny": []
  }
}

sandboxed.sh — Uniqueness & Positioning

Differs from seeds

sandboxed.sh is closest to agent-os (seed) in that both provide a "configuration scaffold" for AI coding agents. But agent-os is a pure bash-script bundle that writes markdown files to disk — sandboxed.sh is a running production server (Rust backend + Next.js dashboard + systemd-nspawn isolation + streaming + iOS app + Telegram bot). The orchestrator-boss/worker skill pattern echoes claude-flow's hive-mind worker pattern, but implemented as persona-md SKILL.md files rather than code classes or SQLite state. The Library's Git-backed skill sync is closest in spirit to spec-driver's (seed) approach of treating skills as versioned artifacts, but sandboxed.sh applies this across multiple agent runtimes simultaneously. No seed provides multi-runtime support (Claude Code + OpenCode + Codex + Gemini + Grok behind one dashboard) or provider fallback chains with health checks.

Positioning

sandboxed.sh targets individual developers or small teams who want to run AI coding agents on their own hardware (a personal server, a cloud VM) with production-quality isolation, multi-runtime support, and remote monitoring. It's a "self-hosted Anthropic Console for your own agents" — complete with mobile apps, Telegram integration, and Library versioning.

Key architectural bets

1. Multi-runtime as a first-class concern — treating Claude Code, OpenCode, Codex, Gemini, and Grok as interchangeable harnesses with a shared Library sync layer
2. Git-backed Library — skills/tools/rules/MCPs are versioned in a git repo, giving them the same change management as code
3. Per-workspace harness architecture — agents run inside the workspace container (not via host proxies), so bash/file operations are naturally scoped
4. Hierarchical boss/worker orchestration in skills — the orchestrator pattern is encoded in SKILL.md files, so it works with any Claude Code session that has the skills loaded

Observable failure modes

• systemd-nspawn + Docker = privileged container — the Docker path requires privileged: true, which significantly weakens isolation guarantees
• Library git sync as single point of failure — if the Library repo is unavailable, mission config writes fail
• Model mixing without type safety — the boss skill guides model choice in prose ("codex for code changes, gemini for proofs"), not enforced routing; wrong model selection is silent
• orchestrator-state.json is hand-maintained — the boss skill mandates updating this file, but there is no platform enforcement; an interrupted boss may leave stale state
• Work-in-progress status — the README explicitly states "Work in Progress"

Cross-references

• Duplicate repo: open-agent-thorgal is the same GitHub repo (Th0rgal/openagent); sandboxed.sh is the canonical slug
• Integrates with: Claude Code, OpenCode, Codex, Gemini, Grok
• Telegram integration for chat-driven missions