The 2,287-file system is a remote coding operations stack
Open-Inspect does much more than queue a prompt. The 2,287-file repository contains a Cloudflare control plane, a Next.js web client, sandbox runtimes, infrastructure packages, and bots for Slack, GitHub, and Linear. Sessions stream in real time, expose a terminal and browser-based VS Code, attribute commits to the person who sent the prompt, and can open pull requests.
The checkout measured 17.4 MB and about 394,860 lines of source before dependencies. A session can include up to 10 repositories, while child sessions run in separate sandboxes and branches. Managed skills can be attached globally or to selected repositories and pinned to a session revision. It needs an owner for authentication, repository scope, secrets, runtime images, spending, and incident response.
Four token types still lead to one shared repository boundary
The README documents 4 token classes for GitHub App work, user pull-request attribution, sandbox calls, and WebSocket connections. That separation limits what each credential does. Repository authorization is much coarser: active users with an eligible workspace role can use any repository available to the shared GitHub App. Open-Inspect does not check each user's own GitHub access when a session begins, so the App installation list becomes the effective repository perimeter.
This is why the project says single tenant in plain language. A multi-tenant version would need separate App installations, access validation at session creation, and tenant isolation in the data model. Even inside one company, install the App only on repositories that every allowed operator may use. The deployment guidance also recommends SSO or a VPN and sign-in restrictions based on named users, email domains, addresses, or GitHub organizations. A broad all-repositories App grant defeats those precautions.
What happened when we ran it
Our sandbox installed commit 52af550 in 38 seconds, adding 1,296 npm packages and occupying 1,184 MB. The build completed successfully in 64 seconds. Npm audit returned 11 known vulnerabilities: 1 critical, 6 high, and 4 moderate. The repository was an npm workspace monorepo, and the lab found 8 CI workflow files plus a Compose file. Those results show the checkout can install and compile in the stated environment.
The test command failed with exit code 1 after 408 seconds. One log summary reported 18 failed and 4,313 passed out of 4,331, followed by 1 error. Other workspace summaries were green, including a Vitest line with 250 passed and 0 failed, plus separate groups of 146, 899, 439, and 1,660 passing tests. Those package-level passes do not cancel the overall failure, and the log tail does not establish the cause of the 18 failures.
The lab ran in a fresh unprivileged Debian container with 3 CPUs, 8 GB of RAM, Node 22, and no secrets. It did not deploy Cloudflare resources, create a GitHub App, start a hosted sandbox, connect a model account, or open a pull request. The 64-second build result therefore covers the source packages, while production behavior still needs a deployment test with the chosen control plane, identity provider, sandbox backend, and repository set.
Node 22 starts the web app, while deployment needs cloud accounts
The root manifest requires Node 22.13.0 or newer. Local web work also needs a development control plane whose browser origin matches localhost, along with its control-plane URL, WebSocket URL, and web service signing secret. GitHub or Google callback URLs must match exactly. Running the UI against a production backend configured for another origin will not authenticate, a useful security property that also makes the local path dependent on a correctly prepared backend.
Full deployment uses Terraform and Cloudflare for the documented control plane, with Vercel or Cloudflare for the web application. Execution runs on Modal, Daytona, Vercel Sandboxes, OpenComputer, or E2B. A GitHub App supplies repository access regardless of the sign-in provider. The operator also creates several independent encryption and service secrets, configures a model API key or supported subscription, bootstraps the first owner, and rebuilds runtime images after provider-account changes.
Ten-repository automations can act without a human present
Automations can fan out across up to 10 repositories from a cron schedule, Sentry alert, completed GitHub workflow, or authenticated webhook. Open-Inspect records run history and pauses an automation after 3 consecutive failures. Slack, GitHub, and Linear bots offer other starting points, while child sessions let a parent delegate work to separate sandboxes. These are useful operations features, and they increase the importance of narrow repository grants, spending limits, secret scopes, and review rules before unattended jobs are enabled.
Repository hooks deserve the same care. A project can define a setup script for dependencies and a start script for services. Setup failures are nonfatal in fresh sessions but fatal while building an image; start failures stop every non-build session. Snapshots and prebuilt images may skip setup, while the start hook always runs. Teams should test each boot mode because a script that behaved correctly in a fresh clone may see different state after an image restore.
September 2026 activity is high, but there is no tagged release
The last push was September 13, 2026. GitHub showed 3,007 stars and 95 combined open issues and pull requests, with several pull requests updated that day. The latest-release endpoint returned no release, and the private root package reports version 0.1.0. This is active software rather than abandoned code, yet adopters have no published release tag to use as a stable change-control boundary. Pinning a commit and maintaining an internal upgrade record is necessary.
The alternatives split the product into smaller decisions. OpenHands is a general coding-agent platform with several interfaces. Vibe Kanban fits local coordination without a shared cloud control plane. Daytona provides sandbox infrastructure and is already one backend Open-Inspect can use. Choose Open-Inspect when multiplayer sessions, bots, schedules, repository environments, and background pull requests belong in one internal system. Begin with repositories that all users may access, keep automation disabled, and require the full test suite to pass on your pinned commit before widening the scope.