Open-Inspect Background Agents
An open-source background coding agent system: agents work autonomously in cloud sandboxes while you dispatch tasks from the web, Slack, GitHub PRs, Linear, or webhooks.
- Source repo
- ColeMurray/background-agents
- Stars
- ★ 3.4k
- Last updated
- today
- License
- MIT
- Primary language
- TypeScript
- FA score
- 77/100 · Good
At a glance
- How it runs
- Works with
- Portable with changesOpenAI API · Claude API
- Cost
- Free software; you pay for model usage
- Setup effort
- High · needs real infrastructure
- You'll need
- Typical use
- Engineering teams offloading refactors and bug fixes to a background agent while members keep working, then reviewing the agent's PRs
- Not a fit if
- Teams needing multi-tenant SaaS isolation — the system is explicitly single-tenant only
- Small teams wanting a zero-infrastructure, minutes-long setup (Cloudflare, sandbox backend, and a GitHub App are required)
- Teams relying on individual users' personal GitHub permissions for session isolation
- Source review
- 77/100 · Good
What does this agent do, and when should you use it?
Open-Inspect (repository ColeMurray/background-agents) is an open-source background agents coding system inspired by Ramp's Inspect. It consists of a control plane (Cloudflare Workers with per-session Durable Objects and a D1 database) and a data plane of session sandboxes hosted on Modal, Daytona, E2B, or Vercel Sandbox, where an OpenCode or Claude Agent harness runs inside a full dev environment with Node.js, Python, git, GitHub CLI, and a headless browser. Tasks arrive from a Next.js web UI, a Slack Bot, a GitHub Bot (auto-review and @mentions), a Linear Bot, or authenticated webhooks; the agent codes in an isolated sandbox and opens PRs attributed to the prompting user. It supports scheduled and event-driven automations, parallel child sessions (spawn-child), multi-repository sessions, and real-time multiplayer collaboration. Model support includes Anthropic Claude, OpenAI Codex, xAI Grok, OpenCode Zen, Z.AI, and DeepSeek, with existing ChatGPT or Claude subscriptions usable. The security model is explicitly single-tenant: all users must be trusted members of one organization.
Users start coding sessions from the web UI, Slack (@mention or DM), the GitHub Bot (auto-review on PR open or @mention in comments), the Linear Bot (issue assignment), or an authenticated webhook POST. The control plane (Cloudflare Workers + one Durable Object per session with SQLite, WebSocket Hub, event stream) dispatches a session sandbox on Modal/Daytona/E2B/Vercel Sandbox, where a Supervisor drives an OpenCode or Claude Agent harness inside a full dev environment (Node.js 24, Python 3.12, Bun, git, GitHub CLI, agent-browser headless Chromium). The agent can split work with spawn-child, send-child-prompt, get-child-status, and cancel-child; on completion it commits with the prompting user's git identity (configureGitIdentity) and opens PRs. Repositories define optional .openinspect/setup.sh and start.sh lifecycle scripts; secrets are AES-256-GCM encrypted and injected as env vars per session. Automations cover cron schedules, Sentry alerts, GitHub Actions workflow-completion events, and inbound webhooks with JSONPath filters, plus fan-out across up to 10 repositories.
- Engineering teams offloading refactors and bug fixes to a background agent while members keep working, then reviewing the agent's PRs
- Slack-based teams: @mention the bot with a screenshot to start a session, with results threaded back into Slack
- Maintainers of open-source or internal repos: let the GitHub Bot auto-review PRs on open or handle @mentions in comments
- Product teams on Linear: assign an issue to the agent to start coding and link the resulting PR back to the issue
- Platform/reliability teams: configure cron or Sentry-alert automations for unattended triage and fixes
- Pair-work scenarios: multiple engineers collaborate in one session in real time, with each prompt attributed to its author in git commits
How do you install or deploy this agent?
The README provides no single copy-paste install command; deployment is documented step by step:
- Fetch the source and read the setup docs:
git clone https://github.com/ColeMurray/background-agents
cd background-agents- Deploy the control plane to Cloudflare (Workers + Durable Objects + D1 database).
- Deploy the sandbox backend: the modal-infra, daytona-infra, or e2b-infra package (no concrete commands in the README).
- Create and install a GitHub App on selected repositories only.
- Configure sign-in restrictions (allowed GitHub users, email domains, or ALLOWED_GITHUB_ORGS).
Missing information: exact wrangler deploy commands, the required environment-variable list, and local dev startup steps live in docs/SETUP_GUIDE.md and docs/GETTING_STARTED.md.
How do you use this agent?
After deployment:
- Follow the first-team setup in docs/GETTING_STARTED.md: create a team, add users, grant repositories.
- Pick repositories (up to 10) or a named environment in the web UI's new-session composer and type a prompt; warming starts as you type.
- Trigger sessions by @mentioning the Slack bot, @mentioning the GitHub Bot in a PR comment, assigning a Linear issue, or POSTing to an authenticated webhook.
- Have the agent split work with spawn-child; watch via the ttyd terminal panel or optional code-server.
- Configure cron schedules, Sentry alerts, or GitHub Actions workflow triggers in Automations for unattended runs; it auto-pauses after 3 consecutive failures.
Required credentials: model credentials (Anthropic API key or Claude subscription, OpenAI ChatGPT subscription OAuth, SuperGrok subscription, or OpenCode Zen) and a GitHub App installation.
What are this agent's strengths and limitations?
- Multiple entry points built in: web UI, Slack, GitHub, Linear, and webhooks — teams trigger agents inside existing workflows
- Fast session startup via layered warming: filesystem snapshots, pre-built images rebuilt every 30 minutes, and proactive warming while you type
- Parallel child sessions (spawn-child) and multi-repo automation fan-out across up to 10 repositories, each with its own session and PR
- Commits attributed to the prompting user with real-time multiplayer streaming — natural fit for supervised team use
- Single-tenant only; multi-tenancy requires per-tenant GitHub Apps, session-creation validation, and data-model isolation you must build yourself
- High infrastructure bar: Cloudflare Workers/D1, a Modal/Daytona/E2B/Vercel sandbox backend, and a GitHub App installation are all required
- Credentials are brokered on demand but cached on disk, so snapshots can retain them; grant removal does not immediately revoke issued tokens
- GitLab credentials are a deployment-wide PAT rather than per-session tokens; the system does not check a user's personal GitHub permissions before creating a session
How does this agent compare with similar options?
The README states the project is inspired by and follows Ramp's Inspect design. Ramp's Inspect is an internal system; this project is the open-source counterpart of the same idea, usable as a self-hosted alternative for internal background coding agents.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Open-Inspect Background Agents This agent | 77 · Good | Self-hosted serviceFree + model costs | ★ 3.4k | today | TypeScript | OpenAI API · Claude API |
| ABCA | 74 · Some gaps | Self-hosted serviceFree + model costs | ★ 162 | 4d ago | TypeScript | Claude Code |
| Agent Kanban | 80 · Good | Self-hosted serviceFree | ★ 491 | 19d ago | TypeScript | — |
| Coven | 79 · Good | CLIFree | ★ 73 | today | Rust | Codex · Claude Code |
How does FollowAgents rate this agent?
Why each dimension lost points
The README limits the system to single-tenant use, recommends SSO/VPN and restricting GitHub App repositories, and describes team authorization, credential caching, and delayed revocation, supporting good least-privilege and data-flow scores. Enforcement still depends on deployment configuration, GitLab uses a deployment-wide PAT, and snapshots can retain cached credentials, so these do not merit full marks. Lifecycle materials require explicit resume after interruption, prohibit automatic replay, and explain uncertain outcomes and recovery boundaries; user confirmation is not a universal prerequisite for every automated external effect. Credential encryption and scoping are described, and dependency locks/build verification have supporting plans, but these files do not establish a complete vulnerability response process. Credits and the MIT license provide some attribution; publisher identity and maintenance responsibility remain unclear.
The materials cover multiple sandbox providers, pause/resume, and snapshot semantics. The ADR and plan describe lifecycle handling for restarts, timeouts, and uncertain outcomes. Documentation spans several providers and some behavior depends on external platform contracts; planned verification is not executed as part of this review, so consistency and dependency availability receive strong but not perfect scores. Failure phases, error metadata, timeouts, and common issues are described specifically, supporting the failure-message score.
The documentation identifies internal background coding scenarios across Web, Slack, GitHub, Linear, webhooks, schedules, and event triggers, with deployment paths for several providers. It clearly states the single-tenant restriction, access boundaries, provider-specific persistence semantics, and recovery guarantees it does not provide. Trigger sources are broad, though some unattended automation paths have less trigger-filter detail. Multi-environment, multi-repository, and deployment configuration are well covered.
The README organizes architecture, packages, setup, features, and security, and links to detailed setup, deployment, and integration guides. The E2B guide includes configuration, build, verification, and troubleshooting. Naming and protocol compatibility decisions appear in an ADR, but Open-Inspect/Background Agents both appear as names and the supplied materials do not establish a formal release history or changelog. Limitations and the MIT license are explicit; maintainer responsibility and support channels are not clear in these files.
The product supports background coding, multiple entry points, multi-repository collaboration, parallel child tasks, and automation, with PR output and prompt-user commit attribution described. Its practical value is clear. Deployment requires cloud services, credentials, provider choice, and operational configuration. Pause and snapshot behavior address cost in some cases, but these materials do not quantify ordinary deployment and maintenance costs, so cost-benefit is not fully established.
Core access boundaries, lifecycle decisions, and dependency build processes are traceable to concrete statements in the supplied files, which distinguish design goals, limits, and provider semantics. The README, ADR, plan, and provider guides corroborate some claims, but many details appear in only one document; planned verification and external provider behavior were not independently confirmed in this static review, so cross-source corroboration is partial.
- The system is explicitly intended for internal single-tenant deployment; do not treat it as a tenant-isolated hosted service.
- GitHub credentials may be cached on disk and retained in snapshots, and removing a team grant does not immediately revoke issued tokens; GitLab uses a deployment-wide PAT.
- Automations can start sessions and produce external effects without a human in the loop; restrict triggers and repository scope carefully.