Open-Inspect: Hintergrund-Agenten für Coding-Aufgaben im eigenen Betrieb
Projektüberblick: Ein Open-Source-Kodierungssystem für Hintergrundagenten. Hintergrundagenten: Open-Inspect Ein Open-Source-Kodierungssystem für Hintergrundagenten, inspiriert von Ramp's Inspect.
Auf einen Blick
- Was ist das?
- ColeMurray/background-agents, bekannt als Open-Inspect, ist ein quelloffenes System für Coding-Agenten im Hintergrund: Sitzungen in Sandboxes, Multiplayer, Automatisierungen und Integrationen für Slack, GitHub und Linear, ausdrücklich als Single-Tenant-Aufstellung konzipiert.
- Für wen ist es gedacht?
- Open-Inspect richtet sich an Teams, die Coding-Agenten hinter ihrem eigenen SSO oder VPN betreiben wollen und deren Mitglieder ohnehin Zugriff auf dieselben Repositories haben. Die Single-Tenant-Ausrichtung mit gemeinsamer GitHub-App ist bewusst gewählt; wer mandantengetrennte Dienste bauen will, müsste laut README Zugriffsvalidierung, eigene App-Installationen und Isolierung im Datenmodell nachrüsten.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Das Repository hat innerhalb des letzten Tages neue Commits erhalten.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich TypeScript, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Open-Inspect: ein Hintergrund-Agentensystem nach Ramps Vorbild
Open-Inspect aus dem Repository ColeMurray/background-agents ist ein quelloffenes System für Hintergrund-Coding-Agenten, das sich vom internen Werkzeug Inspect des Zahlungsdienstleisters Ramp inspiriert zeigt. Das Projekt ist in TypeScript geschrieben, steht unter der MIT-Lizenz und weist 2689 Sterne, 399 Forks und 84 offene Issues auf; der Standardzweig heißt main, die Projektseite läuft unter backgroundagents.dev.
Der Funktionskatalog liest sich wie eine Zusammenfassung dessen, was Hintergrund-Agenten heute können sollen: Der Agent arbeitet an Aufgaben, während der Entwickler anderes tut, erhält eine vollständige Entwicklungsumgebung mit Node.js, Python, git, Browser-Automatisierung und VS Code, und ist von überall erreichbar, über Weboberfläche, Slack, GitHub-Pull-Requests, Linear-Issues oder Webhooks. Hinzu kommen Multiplayer-Sitzungen, Pull Requests mit korrekter Commit-Zuordnung zum anfragenden Nutzer, geplante und ereignisgesteuerte Automatisierungen sowie parallele Unteraufgaben in eigenen Sandboxes.
Das Single-Tenant-Modell und die Token-Architektur
Das README widmet dem Sicherheitsmodell einen eigenen, deutlich formulierten Abschnitt: Das System ist ausschließlich für Single-Tenant-Betrieb entworfen, in dem alle Nutzer vertrauenswürdige Mitglieder derselben Organisation mit Zugriff auf dieselben Repositories sind. Konkret teilen sich alle Nutzer eine gemeinsame GitHub-App-Installation für Git-Operationen. Die Kontrollebene prägt kurzlebige Installationstokens serverseitig und reicht sie über den Git-Credential-Helper an Sandboxes weiter.
Daraus folgt im Klartext: Es gibt keine prüfung der Repository-Berechtigung pro Nutzer vor der Sitzungserstellung, jeder Systemnutzer kann jedes Repository erreichen, auf das die App Zugriff hat. Pull Requests werden für GitHub-Anmeldungen mit dem OAuth-Token des Nutzers erzeugt, was korrekte Zuordnung sichert und die Erstellung auf Repositories mit Schreibrecht begrenzt; wer sich etwa über Google anmeldet, führt kein SCM-Token und fällt auf den gemeinsamen App-Bot zurück. Die Token-Tabelle unterscheidet GitHub-App-Token für clone, fetch und push, Nutzer-OAuth-Token für PRs, Sandbox-Auth-Token und WebSocket-Token, jeweils auf eine einzelne Sitzung begrenzt.
Empfohlene Absicherung und die Grenzen für Multi-Tenant
Für den Betrieb nennt das README vier Empfehlungen: Die Bereitstellung soll hinter dem SSO oder VPN der Organisation erfolgen, damit nur berechtigte Beschäftigte die Weboberfläche erreichen. Die GitHub-App soll nur auf den vorgesehenen Repositories installiert werden, da ihr Installationsumfang definiert, was das System erreichen kann. Die Anmeldung soll beschränkt werden, über erlaubte GitHub-Nutzer, E-Mail-Domänen oder die aktive Organisationsmitgliedschaft mit der Variable ALLOWED_GITHUB_ORGS. Und bei der App-Installation soll die explizite Repository-Auswahl genutzt werden statt der Option alle Repositories.
Wer mandantenfähig aufstellen will, findet im README eine kurze Bedarfsliste: GitHub-App-Installationen pro Mandant, Zugriffsvalidierung bei der Sitzungserstellung und Mandantenisolierung im Datenmodell. Diese drei Punkte sind im heutigen Code nicht enthalten; das Projekt positioniert sich damit ehrlich als Werkzeug für interne Teams und nicht als Plattform für fremde Kunden.
Architektur: Cloudflare-Kontrollebene und wählbare Sandbox-Backends
Die Paketstruktur trennt Kontrollebene und Datenebene. Die Kontrollebene liegt im Paket control-plane und läuft auf Cloudflare Workers mit Durable Objects; das Web-Clients ist eine Next.js-Anwendung im Paket web, und sandbox-runtime enthält die gemeinsame Agent-Laufzeit innerhalb der Sandbox. Für die Sandbox-Infrastruktur gibt es vier austauschbare Pakete: modal-infra, daytona-infra, e2b-infra und opencomputer-infra.
Die Integrationspakete heißen slack-bot für Sitzungen aus Nachrichten, github-bot für automatische Reviews und Erwähnungen, linear-bot für die Erzeugung von Coding-Sitzungen aus Issues, und shared bündelt Typen und Werkzeuge. Diese Aufteilung erlaubt es, die Sandbox-Plattform zu wechseln, ohne die Kontrollebene anzufassen. Die Dokumentation zur Innenansicht liegt in docs/HOW_IT_WORKS.md, die Deploy-Anleitung in docs/GETTING_STARTED.md, die praktische Einrichtung in docs/SETUP_GUIDE.md.
Schnellstart durch Snapshots, vorbereitete Images und Aufwärmung
Der Sitzungsstart ist eine der sichtbarsten Stärken. Das README beschreibt mehrere Ebenen der Aufwärmung: Nach jedem Prompt wird der Sandbox-Zustand als Dateisystem-Snapshot gesichert, sodass Folgesitzungen wiederhergestellt werden statt neu zu klonen. Vorbereitete Images lassen sich pro Repository unter Settings, Images, oder pro Umgebung unter Settings, Environments, einschalten und werden alle 30 Minuten mit den neuesten Commits und Abhängigkeiten neu gebaut.
Die dritte Ebene ist proaktiv: Die Sandbox beginnt bereits anzulaufen, sobald der Nutzer zu tippen anfängt, noch vor dem Drücken der Eingabetaste. Zusammengenommen soll das die Zeit zwischen Aufgabenstellung und arbeitsfähiger Umgebung stark verkürzen. Für wiederkehrende Konfiguration erlaubt das System außerdem verwaltete Agent-Anweisungen, dokumentiert in docs/MANAGED_SKILLS.md.
Multi-Repository-Sitzungen, Umgebungen und Multiplayer
Eine Sitzung kann über mehrere Repositories gleichzeitig arbeiten. Im Auswahlmenü für neue Sitzungen lassen sich bis zu zehn Repositories wählen; jedes wird nebeneinander in dieselbe Sandbox geklont, und der Agent kann koordinierte Änderungen machen und pro Repository einen eigenen Pull Request öffnen. Solche Zusammenstellungen lassen sich als benannte Umgebungen speichern, mit eigenem Geheimnisumfang und optional vorbereiteten Images.
Der Multiplayer-Betrieb erlaubt mehreren Personen die gleichzeitige Arbeit in einer Sitzung, mit Präsenzanzeige, Streaming an alle verbundenen Clients und Prompts, die den Autoren in den Git-Commits zugeordnet bleiben. Damit passt das System für Fälle, in denen ein Team eine komplexe Änderung über mehrere Teilprojekte hinweg gemeinsam durch einen Agenten begleitet, etwa Frontend, Backend und Infrastruktur-Repository in einer Aufstellung.
Automatisierungen: Cron, Sentry-Warnungen und Webhooks
Automatisierungen laufen laut docs/AUTOMATIONS.md ohne menschliches Zutun. Für Zeitpläne gibt es stündliche, tägliche, wöchentliche und monatliche Intervalle oder einen benutzerdefinierten 5-Feld-Cron mit Zeitzonenunterstützung. Ereignisgesteuert reagiert das System auf Sentry-Warnungen zur automatischen Triage neuer Fehler oder Regressionen sowie auf eingehende Webhooks, deren Auslösung über JSONPath-Bedingungsfilter eingeschränkt werden kann.
Für den Produktionsbetrieb sind die Schutzmechanismen bemerkenswert: Eine einzelne geplante Automatisierung kann auf bis zu zehn Repositories ausgeweitet werden und öffnet für jedes eine eigene Sitzung mit eigenem Pull Request. Nach drei aufeinanderfolgenden Fehlern pausiert die Automatisierung automatisch, daneben gibt es eine manuelle Auslöseschaltfläche und eine vollständige Ausführungshistorie. Damit bleibt ein Agentenlauf, der aus dem Ruder läuft, begrenzt und nachvollziehbar.
Lebenszyklus-Skripte, Lizenz und Einordnung
Repositories können optionale Skripte unter .openinspect/ definieren. setup.sh läuft bei Image-Builds und frischen Sitzungen, wird aber bei Starts aus vorbereitetem Image oder Snapshot-Wiederherstellung übersprungen; sein Scheitern ist für frische Sitzungen nicht fatal, im Image-Build-Modus dagegen schon. start.sh läuft bei jedem übrigen Sitzungsstart und fällt streng aus, die Sitzung bricht bei Fehlern ab. Beide Skripte erhalten die Variable OPENINSPECT_BOOT_MODE mit den Werten build, fresh, repo_image oder snapshot_restore; die Zeitüberschreitungen stehen über SETUP_TIMEOUT_SECONDS mit 300 und START_TIMEOUT_SECONDS mit 120 Sekunden.
Die Lizenz ist MIT, den Copyright-Vermerk tragen die Open-Inspect Contributors. Insgesamt positioniert sich das Projekt als eine in sich geschlossene Antwort auf die Frage, wie ein Team Hintergrund-Agenten in eigener Kontrolle betreibt: mit klarer Aussage zu den Sicherheitsgrenzen, austauschbarer Sandbox-Infrastruktur und Integrationen, die Arbeitsabläufe aus Slack, GitHub und Linear heraus starten, statt sie umzukehren.
Redaktionelles Fazit
Open-Inspect richtet sich an Teams, die Coding-Agenten hinter ihrem eigenen SSO oder VPN betreiben wollen und deren Mitglieder ohnehin Zugriff auf dieselben Repositories haben. Die Single-Tenant-Ausrichtung mit gemeinsamer GitHub-App ist bewusst gewählt; wer mandantengetrennte Dienste bauen will, müsste laut README Zugriffsvalidierung, eigene App-Installationen und Isolierung im Datenmodell nachrüsten. Einstiege bieten docs/SETUP_GUIDE.md, docs/GETTING_STARTED.md und docs/HOW_IT_WORKS.md im Repository ColeMurray/background-agents, die Lizenz ist MIT.
Community-Notizen