Feature Guide

The 20 features worth knowing.

The features page is the one-liner tour. This is the deep dive — real commands, real config keys, and the scenarios where each feature is the right tool for the job.

Orchestration & automation

Multi-agent support

One Web UI, many "brains." Pick the CLI agent that fits the job — Claude Code, Codex, Cline, Gemini, OpenCode, DeepAgents, Grok Build, Pi, Continue, Copilot, browser-use, OpenHands, or the generic llm agent for any model in Simon Willison's llm CLI plugin ecosystem — without changing how you start, monitor, or review jobs.

How to use it

  • Open the Web UI at https://localhost:6886 and pick an agent from the dropdown in the Start New Job form.
  • Or start one from the sandbox CLI inside a manager-mode agent job: bin/sandbox start codex "Fix bug" -w /app/workspace/myproject.
  • Every agent type shares the same job lifecycle, terminal, git tooling, and task board — switching agents doesn't mean switching workflows.
  • Agent availability depends on your build path: the open-source build (make start-open-source) ships an open-source agent set out of the box; additional vendor CLIs (e.g. Claude Code) are added via the optional local-vendor path (make install-agents) after reviewing that vendor's terms.

Use cases

  • Run the same prompt against two different models/agents side by side to compare output quality before trusting either one unsupervised.
  • Use a cheap, fast agent (e.g. an OpenAI-compatible model via the generic llm agent) for straightforward Q&A or code review, and reserve a heavier agentic tool for multi-file refactors.
  • Standardize a team on one workflow (task board, terminal, git review) even though different engineers prefer different underlying coding assistants.

Manager mode & sandbox CLI

Let one agent start, monitor, and control other agents through bin/sandbox — the CLI behind Manager Mode. It's how you build a "mayor" agent that delegates work to a fleet of worker agents and supervises them, instead of babysitting each one yourself.

How to use it

  • Enable the Manager Mode capability toggle when starting a job (write operations require it; without a manager token the CLI is read-only).
  • List and inspect other jobs: bin/sandbox jobs, bin/sandbox status <suffix>, bin/sandbox log <suffix> -n 50.
  • Start and link work to a task: bin/sandbox delegate claude "Fix the login validation bug" -t task-abc123 -w /app/workspace/myproject.
  • Block until a worker finishes, or live-follow it: bin/sandbox wait <suffix> --timeout 900 or bin/sandbox watch <suffix> --interval 15.
  • Recover a stuck worker: bin/sandbox status <suffix> → bin/sandbox kill <suffix> → bin/sandbox restart <suffix>.

Use cases

  • Fan out a "audit the auth module" task and a "write missing tests" task to two workers in parallel, then poll both and merge results.
  • Build a supervising agent that periodically nudges a long-running worker (bin/sandbox send <suffix> "status?") instead of a human checking in.
  • Kill and restart a worker that has gone quiet or looped, without a human needing to open the Web UI.

Job queue

Stage jobs instead of firing them immediately. Queue missions, reorder them, delay auto-dispatch by up to 12 hours, and dispatch them to specific nodes — useful for batching work without needing every job to start the instant you write the prompt.

How to use it

  • In the Start New Job form, click Queue Mission instead of Launch to add the configured job to the queue.
  • Use the "Start in" selector to delay auto-dispatch by 1–12 hours, or leave it immediate.
  • Manage the queue from the Job Queue section: Start Next, Start All, per-row move up/down, per-row Start/Remove.
  • Via API: POST /api/queue to add, POST /api/queue/reorder to reposition, POST /api/queue/start to start the next (or a specific) job.

Use cases

  • Queue up a night's worth of independent chores (dependency bumps, doc refreshes, lint fixes) before you leave, and let them dispatch sequentially overnight.
  • Batch a set of related fixes and control the order they land in, so a later job can rely on an earlier one's output.
  • Stage jobs against a specific remote node while the primary node is busy, without losing your place in line.

Context teleport

Package a job's git state, transcript digest, task context, and original prompt into a bootstrap prompt for a successor agent — either to hand off a stalled job (rate-limited, erroring) or to clone a session's context into a new agent for a different goal.

How to use it

  • Open the Teleport button on any job's detail modal (running or stopped); keyboard shortcut Ctrl+J / Cmd+J submits the modal.
  • Choose Handoff mode to continue in-progress work on a new agent, or Clone mode to give a new agent full context for a different task.
  • From the CLI (manager mode required): bin/sandbox teleport <suffix> --preview to inspect the capsule first, then bin/sandbox teleport <suffix> -a codex -i "Continue from auth fix".
  • Clone with full context: bin/sandbox teleport <suffix> --mode clone -i "Write tests for the middleware you just fixed".

Use cases

  • A job hits an API rate limit or repeated errors mid-task — teleport it to a fresh agent (same or different type) instead of losing the work already done.
  • Spin up a second agent that already understands the current repo state (git branch, recent transcript) to start a related but distinct task, without re-running discovery.
  • Fail over from one LLM provider to another mid-session when a provider is down, keeping the git branch and task linkage intact.

Cron scheduling

Schedule agent jobs to run once at a specific time or recurring on a cron expression — nightly reviews, periodic audits, or a one-off job queued for later — all managed centrally from the Cron tab.

How to use it

  • Open the Cron tab in the Web UI to create, edit, pause/resume, or run-now a scheduled job, and review execution history.
  • Create a recurring job via API: 
    curl -X POST https://localhost:6886/api/cron/jobs \
  -u "admin:${AUTH_PASSWORD}" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "nightly-review",
    "schedule_type": "recurring",
    "cron_expression": "0 2 * * *",
    "timezone": "UTC",
    "workdir": "/app/workspace/myproject",
    "prompt": "Review all recent commits for security issues"
  }'
  • Create a one-time job by setting "schedule_type": "once" and "one_time_at": "2026-01-28T18:00:00Z" instead of a cron expression.
  • Save recurring configs as templates and export/import scheduled jobs as JSON via /api/cron/export and /api/cron/import.

Use cases

  • Run a nightly agent that reviews the day's commits for obvious security issues before anyone's even at their desk.
  • Schedule a one-time job for "prepare the database migration scripts" at a specific cutover time.
  • Run a recurring dependency or lint audit every few hours on a busy repo, independent of any individual developer remembering to trigger it.

CI webhook autofix

Point a CI pipeline's failure webhook at Agent Starbase and it queues an agent job to fix the failure automatically — with a purpose-built prompt for the specific failure type (RSpec, Vitest, Prettier, license scan, or a generic step).

How to use it

  • POST failure details (using the main web-ui credentials for HTTP Basic auth) to /api/webhook/ci: 
    curl -u "admin:${AUTH_PASSWORD}" -X POST https://localhost:6886/api/webhook/ci \
  -H 'Content-Type: application/json' \
  -d '{
    "repo": "myproject",
    "step": "rspec",
    "branch": "main",
    "commit_sha": "abc1234",
    "files": "spec/models/user_spec.rb",
    "output": "1) User validates email\n   Failure/Error: ..."
  }'
  • The step field selects a tailored fix prompt: prettier runs npx prettier --write, rspec/vitest get root-cause-fix instructions with explicit "do not skip or delete failing tests" guardrails, license-scan gets an advisory investigate-and-document prompt.
  • For server errors on already-checked-out code (Rails apps, etc.), use /api/webhook/server-error instead — it skips the git pull/push step since the code is already there.
  • The queued job runs with dind: true automatically for rspec/vitest steps so it can reach a real test database.

Use cases

  • Wire your CI pipeline's failure notification straight to Agent Starbase so a broken test suite gets an automatic first-pass fix attempt before a human even looks at it.
  • Auto-fix formatting-only CI failures (Prettier) without interrupting a developer's flow.
  • Let a production error-tracking webhook dispatch an investigate-and-fix job against the already-checked-out branch, no manual repro needed.

Task & knowledge management

Task tracking with dependencies

A persistent, PostgreSQL-backed task board that gives agents structured memory across sessions — solving the "every session starts from zero" problem. Tasks carry status, priority, blocker dependencies, notes, and multi-assignee claims, so agents (and humans) can resume interrupted work.

How to use it

  • Preferred: the bin/atask CLI, which wraps the v2 task API and handles auth automatically: 
    bin/atask ready                     # unblocked tasks to pick up
bin/atask claim task-abc12345       # set in_progress + assign yourself
bin/atask note task-abc12345 "Found root cause in auth middleware"
bin/atask review task-abc12345      # code done, awaiting human review
bin/atask complete task-abc12345 "Fixed email validation regex"  # after human approval
  • Add a dependency so one task blocks another: bin/atask block <blocked-id> <blocker-id>.
  • Lifecycle is pending → in_progress → to_review → completed; agents set to_review, only humans set completed.
  • Raw API alternative: curl -u "$TASK_AUTH_USERNAME:$TASK_AUTH_PASSWORD" http://web-ui:4567/api/v2/tasks/ready?project=agent-starbase.

Use cases

  • Break a large migration into 40 dependent tasks and let agents pick up whatever is unblocked next, without a human manually sequencing the work.
  • Recover from an agent session that got interrupted (rate limit, crash) — the next session reads task notes and picks up exactly where the last one left off.
  • Give a human reviewer a single "awaiting review" queue (bin/atask reviews) instead of hunting through chat logs for what's done.

Prompt templates

Save reusable prompt snippets and compose them inline with {{template-name}} syntax. A short reference like {{read_docs}} expands to a full multi-line preamble at send time — the agent never sees the raw braces, and the whole team's agents get briefed the same way.

How to use it

  • Type {{template-name}} anywhere in a prompt; it expands on submission. E.g. {{read_docs}} Fix the login bug in auth.rb.
  • Click Templates in the Start New Job form to create, edit, or delete templates, and see which templates reference which ("Used by").
  • Give a template a project-scoped override so {{read_docs}} means something different for different repos.
  • Variables work too: {{var:default}} is user-fillable with a default; template names always win over variable names of the same name.
  • API: POST /api/prompt-templates/expand with {"text": "{{read_docs}} Fix the bug", "workdir": "/app/workspace/myproject"} to resolve a prompt server-side.

Use cases

  • Standardize "read the docs before changing anything" or "verify the task is actually done" instructions across every agent job on the team, editable in one place.
  • Give each repository its own definition of what "read the docs" means via project-scoped overrides, without maintaining separate prompt libraries per repo.
  • Let less-experienced teammates start well-briefed jobs by tapping template chips instead of retyping boilerplate context every time.

Find a specific past job among hundreds by prompt text, log content, exit code, duration, agent type, or date range — a cross-agent search interface backed by a PostgreSQL trigram index, with an optional grep pass over the actual log file.

How to use it

  • Open the Session Search plugin tab in the Web UI's Tools section.
  • Filter by Prompt contains, Log contains, Exit code (Any/Success/Failed/Custom), Duration, Agent, and Date range.
  • Via API: GET /api/sessions/search?prompt=auth&exit_code=%210&agent_type=claude&limit=20.
  • Each result shows a matching log line with one line of context before/after, and buttons to open the Log Modal, Job Detail Modal, or Terminal for running sessions.

Use cases

  • Track down the one session, out of hundreds, that touched a specific file or produced a specific error message.
  • Audit every failed job (exit_code=!0) from the last 7 days across all agent types in one query.
  • Find a past session by a fragment of what you remember typing in the prompt, without scrolling the full job list.

Transcript sharing

Export an immutable, filtered snapshot of a structured agent transcript — full session or a selected event range — as a public URL, or download it as HTML, JSON, flat Chat JSON (for pasting into another LLM), or PDF.

How to use it

  • Open a job with structured transcript support, switch to the transcript view, and click Share.
  • Choose Full transcript or select a Start/End event range; hide any individual messages that shouldn't be included.
  • Pick a format — URL, HTML, JSON, Chat, or PDF (PDF requires headless Chromium in the runtime image) — and click Create share.
  • Shares can expire after 7 or 30 days, or never; revoke a share to make its public URL return 404 immediately.

Use cases

  • Send a teammate a link to exactly the part of an agent session that explains a tricky decision, without giving them terminal access.
  • Export a session as flat Chat JSON and paste it into a different LLM chat to get a second opinion, with full conversational context intact.
  • Archive a completed job's transcript as a durable JSON snapshot for later audit, independent of whether the underlying job log is ever cleaned up.

Security & cost

Hardened container isolation

Every agent runs in its own container as a non-root user with setuid binaries stripped, hard resource caps, and no default credentials — so a misbehaving or malicious agent job can't escalate privileges or take down the host.

How to use it

  • Start the stack normally with make start-open-source — hardening is baked into the image and compose config, not something you opt into per job.
  • Check live resource usage: docker stats agent_starbase_agent.
  • Inspect the container from inside: make shell-running, then confirm you're non-root and can't escalate.
  • Passwords (web UI, database, gateway key) are generated randomly on first run and written to .env — nothing ships with "admin/admin".

Use cases

  • Let an agent run rm -rf-style destructive commands against its own workspace with confidence that a runaway process can't touch the host or other containers.
  • Run untrusted or experimental agent prompts (e.g. testing a new agent CLI) without expanding your host's attack surface.
  • Satisfy an internal security review that requires proof of non-root execution and capability stripping for any code-executing service.

Proxy-enforced egress

Agent containers cannot reach the internet directly — iptables blocks all outbound traffic except to the Squid proxy, which enforces a domain whitelist and logs every request. Modes are hot-swappable, so you can loosen or tighten network access without rebuilding.

How to use it

  • Switch modes: make proxy-strict (Anthropic API only), make proxy-default (approved AI providers + GitHub for Copilot jobs; package registries blocked), make proxy-open (everything, still logged — for discovering what a new integration needs).
  • Watch traffic live: make proxy-logs or tail -f proxy/logs/access.log.
  • Find what a new tool needs: switch to open mode, run it, then make proxy-analyze to see what domains it hit, and add them to proxy/squid.conf.
  • Verify from inside a job: curl https://api.anthropic.com should work; curl https://google.com should fail unless whitelisted.

Use cases

  • Run an agent with confidence it can't exfiltrate your codebase or secrets to an arbitrary endpoint, even if it were tricked into trying.
  • Onboard a new dependency or API integration by discovering its exact required domains in open mode, then lock back down to a minimal explicit whitelist.
  • Produce an audit trail of every outbound request an agent made during a job, for compliance or incident review.

Cost & usage tracking

Real-time and historical LLM spend tracking, with prompt-cache-aware accounting (cache writes and cache reads costed separately) so the numbers line up with your actual provider bill, plus a live 5-hour Claude usage window before you start a new job.

How to use it

  • The Start New Job form shows the current Claude 5-hour window (Usage left, Resets) automatically before you launch.
  • Open the Usage tools tab for a fuller breakdown: remaining %, reset countdown, and a model-scope filter.
  • Query token/cost history by agent and period: GET /api/usage/agent?agent=claude&period=monthly&start_date=2026-04-01&end_date=2026-04-30.
  • Query per-job usage: GET /api/usage/job?agent=claude&suffix=<job-suffix>, or gateway-routed provider usage: GET /api/usage/providers?period=monthly.
  • CLI: ccusage blocks --active --json --offline for the fastest local check.

Use cases

  • Catch a runaway agent loop burning tokens before it drains your 5-hour Claude window or blows your monthly OpenRouter budget.
  • Reconcile Agent Starbase's reported spend against your actual provider invoice, including prompt-cache write/read cost multipliers that are easy to miscalculate by hand.
  • Attribute cost per project or per agent type when multiple teams share one Starbase deployment.

Developer workflow

Live virtual terminal

Watch an agent work in real time through a browser-rendered terminal backed by the actual tmux session — readable HTML output with live WebSocket streaming, plus a structured "transcript mode" that shows turn boundaries (assistant blocks, tool calls, results) instead of raw ANSI noise.

How to use it

  • Click the terminal button on any running job in the job list, or open the Terminal page directly.
  • Switch between Rendered mode (tmux output as styled HTML) and Transcript mode (structured turns, auto-selected for Claude Code, Codex, OpenCode, Pi, and Grok Build jobs).
  • Use the input bar at the bottom to send commands straight to the real tmux session — line editing and shell history work exactly as they would in a normal terminal.
  • Search with Ctrl+F/Cmd+F; fall back to the "Raw terminal" (xterm.js) button for cursor-addressed programs (vi, htop, interactive prompts) that the HTML view can't render.

Use cases

  • Watch a long agentic run in progress and step in with a clarifying instruction the moment it looks like it's about to go off track.
  • Read back exactly what tool calls an agent made and why, in transcript mode, without parsing raw terminal escape codes.
  • Take over an agent's tmux session directly (e.g. to answer an interactive CLI prompt it's stuck on) without SSHing into the container.

Git integration

Clone, diff, commit, and merge without leaving the browser. Includes AI-generated commit messages (with automatic fallback models on failure), a worktree-aware workflow, and SSH-authenticated cloning via a dedicated git-helper daemon.

How to use it

  • Clone a repo from the Git section: paste a URL (HTTPS or git@ SSH), optionally override the target path, click Clone. API: POST /api/git/clone-project with {"url": "...", "target_path": "..."}.
  • Review and commit from the Git Commit tab (main UI) or the Git Commit modal in Terminal — both support diff viewing, staging, and branch merging.
  • Stage files, then click Summarize to generate a commit message from the staged diff via a configurable model (default grok-code, with fallback models on error).
  • Merge branches with the Merge button next to + Branch — pick a source branch from the dropdown and Execute Merge.

Use cases

  • Review an agent's changes the same way you'd review a PR — diff, commit message, merge — all inside the same UI you started the job from.
  • Clone a private repo via SSH straight into the workspace to hand an agent a fresh codebase, without shelling in to run git clone manually.
  • Let an agent's changes get an AI-drafted commit message so a human only has to review and tweak it, not write it from scratch.

File browser & code editing

Browse, fuzzy-search, view, and edit any file across all workspace directories from the browser — with syntax highlighting, markdown/HTML rendering, and an optional upgrade to a full code-editor experience when the Code IDE plugin is enabled.

How to use it

  • Open the File Browser tab in Tools. Use Tree View for hierarchical navigation or Search for fuzzy filename/path matching (e.g. typing gitfeat finds GitFeatures.js).
  • Click any file to open the view modal — toggle Line numbers, Wrap text, Render Markdown, or Render HTML (sandboxed iframe preview) as needed.
  • Click Edit to modify a file in place; Ctrl+S/Cmd+S saves, Esc closes.
  • With the Code IDE plugin enabled, the edit modal upgrades automatically to a full syntax-highlighted editor — no separate setup required.

Use cases

  • Spot-check a file an agent just touched without opening a full IDE or SSHing into the container.
  • Preview a generated HTML report or rendered markdown doc directly in the browser, sandboxed from the rest of the UI.
  • Make a quick manual tweak to a config file mid-job without stopping the agent or opening a terminal.

Browser verification (ShowOff)

ShowOff drives a real browser so an agent can visually prove frontend work — screenshots get uploaded as task attachments for reviewer inspection. Supports headless (Rodney), DinD-networked, and the Steel driver with live agent-to-human handoff for logins or 2FA.

How to use it

  • Headless, no DB dependency: 
    showoff start --task task-abc123 --run "npm run dev" --port 3000
showoff browse http://localhost:3000/login
showoff fill "#email" "user@example.com"
showoff click "#submit"
showoff assert-text "Dashboard"
showoff finish
  • For apps needing DinD services (Postgres, etc.) or user collaboration, use the Steel driver: showoff start --task <TASK-ID> --driver steel --network myproject_default, then showoff browse ....
  • Hand off to a human when stuck (e.g. login/2FA): showoff handoff --reason "Need 2FA login" --wait — the user takes control in their browser, then the agent resumes.
  • Run showoff health (alias showoff doctor) to verify Docker reachability, the test compose file, and browser prerequisites before debugging further.

Use cases

  • Prove a UI fix actually renders correctly — screenshot attached to the task — instead of asking a reviewer to trust the diff.
  • Check translations or layout across locales by setting localStorage language before navigating and screenshotting each one.
  • Get unstuck on a login wall that needs 2FA by handing control to a human mid-session, then resuming automated verification once past it.

Multi-provider LLM support

Configure multiple OpenAI-compatible and Anthropic-compatible endpoints side by side — OpenRouter, OpenAI, DeepSeek, Ollama, Z.AI/GLM, MiniMax, a self-hosted LiteLLM gateway, or any vendor that implements the relevant API — and route individual jobs to whichever provider fits.

How to use it

  • Open Settings → LLM Providers, pick a preset (OpenRouter, OpenAI, DeepSeek, Ollama, Anthropic, Z.AI/GLM, Moonshot Kimi, MiniMax, or Custom) or fill in a custom base URL, and click Test to verify connectivity.
  • Models from all enabled providers aggregate into one dropdown, grouped by provider, when starting a job.
  • Look up which provider a model resolves to before starting a job: bin/aproviders lookup glm-5, or search for the right canonical ID: bin/aproviders models glm.
  • List configured providers and refresh the cached model list: bin/aproviders list --refresh.

Use cases

  • Point cost-sensitive batch jobs at a cheaper provider (Ollama locally, or a discounted OpenRouter model) while keeping premium jobs on a stronger model.
  • Fail over to a second provider automatically when your primary is rate-limited or down, without reconfiguring every job by hand.
  • Run fully offline/air-gapped with a local Ollama or LM Studio endpoint for jobs that shouldn't touch the public internet at all.

Input & accessibility

Multimodal input (images & voice)

Attach screenshots, mockups, or diagrams to a prompt for multimodal tasks, or dictate a prompt out loud and have it transcribed automatically — both delivered directly into the same Start New Job form you already use.

How to use it

  • Attach images via drag-and-drop, the Browse button in the dropzone, or clipboard paste (Ctrl+V/Cmd+V) — up to 5 files, 5 MB each, 30 MB total request size.
  • For Claude Code jobs run with --print, images are embedded as base64 directly in the conversation from the first turn (stream-JSON mode); otherwise they're saved to disk and referenced by file path in the prompt.
  • Dictate a prompt: click the microphone button (or Ctrl+M/Cmd+M) in the Start New Job form, speak, click again to stop — text is transcribed via OpenAI GPT-4o transcription and inserted at the cursor.
  • Voice input requires the proposal_microphone_input feature flag enabled and an OpenAI transcription key configured (OPENAI_API_KEY on the web-ui container or saved in Settings).

Use cases

  • Drop in a screenshot of a broken layout and ask the agent to fix the CSS that produced it, without describing the bug in words.
  • Attach a UI mockup or diagram as the spec for a new feature the agent should implement.
  • Dictate a prompt hands-free while reviewing a bug report on another screen, instead of typing it out.

Internationalization

The Web UI ships in 15 languages via a lightweight client-side i18n system, so teams can work in the language they think in rather than being locked to English.

How to use it

  • Language auto-detects from the browser's navigator.language; override it in the settings panel — the choice persists in localStorage.
  • Supported locales: English, Chinese (Simplified, Cantonese/HK, Taiwan), French, German, Russian, Spanish, Japanese, Brazilian Portuguese, Korean, Turkish, Italian, Dutch, and Polish.
  • Check translation coverage or find gaps with the built-in CLI: bin/i18n summary, bin/i18n missing [locale], bin/i18n missing-by-feature [locale].
  • Add a new language by copying web/agent-sandbox-ui/locales/en/ to a new locale directory, translating the values (keys stay unchanged), and registering the code in the language selector.

Use cases

  • Run a distributed team where engineers in different regions each use the Web UI in their native language.
  • Localize an internal deployment for a non-English-speaking department without forking the codebase.
  • Audit translation completeness before a release with bin/i18n summary instead of manually eyeballing each locale file.
Going deeper? The full internal docs for every feature live in the repo under docs/core/features/ — this guide covers the top 20 for evaluation purposes. See the Docs page for setup and architecture.

See it running in five minutes.

Community edition is free, self-hosted, and Apache 2.0. No signup required.

Read the quick start →