Background Agents: Open-Inspect

English | 简体中文

An open-source background agents coding system inspired by Ramp's Inspect.

Overview

Open-Inspect provides a hosted background coding agent that can:

• Work on tasks in the background while you focus on other things
• Access full development environments (Node.js, Python, git, browser automation, VS Code)
• Connect from anywhere — web UI, Slack, GitHub PRs, Linear issues, or webhooks
• Enable multiplayer sessions where multiple people can collaborate in real time
• Create PRs with proper commit attribution to the prompting user
• Run scheduled automations for cron jobs, or event-driven automations for GitHub events, Sentry alerts, and webhooks
• Spawn parallel sub-tasks that work in separate sandboxes simultaneously
• Use your choice of AI model — Anthropic Claude (via API key or a connected Claude subscription on the Claude Agent harness), OpenAI Codex (via ChatGPT subscription), xAI Grok (via SuperGrok subscription), or OpenCode Zen

Security Model (Single-Tenant Only)

Important: This system is designed for single-tenant deployment only, where all users are trusted members of the same organization. Teams add internal access controls, not tenant isolation.

How It Works

Teams own sessions, environments, and automations. A session's Workspace, Team, or Private visibility is separate from its fixed ownership; resources cannot move between teams or to/from the workspace. Team-owned session actions require current owning-team membership, even for workspace Owners and Administrators. With enforcement on, deletion additionally requires sessions.delete and being the session owner, an owning-team lead, or a workspace administrator; team-owned and private sessions apply their action checks in every mode.

Private sessions are readable by their owner and explicit collaborators. Workspace Owners have an audited break-glass read path, not automatic collaboration or sandbox access. Team visibility's read boundary requires TEAMS_ENFORCEMENT=on; the deployment default remains shadow.

For a single-team deployment, create one team, add the users who need to act on its sessions, and grant its repositories. Existing workspace-owned rows are not moved or hidden. Even with every user in one team, being a Member does not let someone delete another member's session under enforcement unless they satisfy the ownership/lead rule. Follow the first-team setup before inviting users.

The shared GitHub App installation bounds workspace repository reach. Sandbox git credentials are limited to the session's persisted repositories and, for team-owned sessions, current owning-team grants. Workspace permissions and resource access still apply; Open-Inspect does not compare a user's personal GitHub repository permissions before creating a session. GitLab credentials remain a deployment-wide PAT rather than a per-session token.

Credentials are brokered on demand but cached on disk, so snapshots can retain them. Grant removal does not immediately revoke issued tokens. See the canonical Authentication and Authorization guide for access rules and credential boundaries, including user versus App identity and snapshot limitations.

Why Single-Tenant Only

This architecture follows Ramp's Inspect design, which was built for internal use where all employees are trusted and have access to company repositories.

For multi-tenant deployment, you would need:

• Per-tenant GitHub App installations
• Access validation at session creation
• Tenant isolation in the data model

Deployment Recommendations

1. Deploy behind your organization's SSO/VPN - Ensure only authorized employees can access the web interface
2. Install GitHub App only on intended repositories - The App's installation scope defines what the system can access
3. Restrict sign-in - Configure allowed GitHub users, email domains, or active GitHub organization membership (ALLOWED_GITHUB_ORGS)
4. Use GitHub's repository selection - When installing the App, select specific repositories rather than "All repositories"

See Authentication and Authorization for workspace roles, session access, automation ownership, bots, and member suspension.

This is the beginning of the README. Read the rest at the original. Read the full README ↗