Arbeitsbereiche und Isolation

Was ist ein Arbeitsbereich?

Ein Arbeitsbereich ist der oberste Isolationsmandant in Control Center. Er fasst Agenten, Repositorys, Bereiche, Tickets, Gedächtnis, Pipelines und Mitglieder zu einem abgegrenzten Kontext zusammen. Alles, was in einem Arbeitsbereich geschieht, bleibt darin.

Ein typischer Arbeitsbereich entspricht einem Projekt oder einer Codebasis. Du kannst getrennte Arbeitsbereiche für „api-service“, „frontend-v2“ und „infrastructure“ führen.

Arbeitsbereichsbezogene Daten

Die Zeilen eines Arbeitsbereichs liegen in der eigenen SQLite-Datei dieses Arbeitsbereichs, unter <dataDir>/<workspaceId>/workspace.db. Jeder Arbeitsbereich bekommt ein Verzeichnis statt einer bloßen Datei, weil ein Arbeitsbereich mehr ansammelt als eine Datenbank — Worktrees je Unterhaltung, die Agenten- und Skill-Dateien, Zugangsdaten des Chat-Bots — und ein Ordner heißt, dass all das gemeinsam lebt und gemeinsam gelöscht wird.

Entität	Geltungsbereich
Agenten	Gehören zu genau einem Arbeitsbereich
Repositorys	In einen Arbeitsbereich registriert (siehe unten)
Bereiche, Unterhaltungen und Nachrichten	Arbeitsbereichsbezogen
Tickets, Projekte, Pläne, Orchestrierungen	Arbeitsbereichsbezogen
Gedächtnisfakten, Richtlinien, Domänen, Zugriffs-Grants	Arbeitsbereichsbezogen
Pipeline-Läufe, Vorlagen, Trigger	Arbeitsbereichsbezogen
Pull-Request-Zustand, Review-Bereiche, Review-Kohorten	Arbeitsbereichsbezogen
Laufprotokolle der Agenten und Arbeitsgedächtnis	Arbeitsbereichsbezogen
Mitglieder, Einladungen, Freigaben pro Repo	Arbeitsbereichsbezogen
Symbole und Kanten des Code-Graphen	Nach `repoId` in der Datei des Arbeitsbereichs abgegrenzt

Die meisten dieser Zeilen tragen eine Spalte workspaceId; getrennte Datenbankdateien setzen die Isolation durch. Siehe die Isolationsinvariante unten.

Repos sind an den Arbeitsbereich gebunden; die Identität über Arbeitsbereiche hinweg ist der Pfad

Eine Repo-Zeile lebt in der eigenen Datenbankdatei ihres Arbeitsbereichs — die Datei ist der Geltungsbereich, deshalb hat die Tabelle keine Spalte workspaceId und keine Join-Tabelle.

Ein Repo fügst du unter Einstellungen → Arbeitsbereich → Repositorys zu einem Arbeitsbereich hinzu. Denselben Checkout in zwei Arbeitsbereichen zu registrieren erzeugt zwei unabhängige Zeilen mit zwei IDs; die Identität eines Repos über Arbeitsbereiche hinweg ist der Dateisystempfad (oder GitHub-Owner/Name), nie die ID.

Die Registrierung ist streng: Der Pfad muss in einem Git-Arbeitsbaum liegen, er muss ein origin-Remote haben, und dieses Remote muss auf eine unterstützte Forge zeigen (github.com, gitlab.com oder bitbucket.org). Die Forge wird vom Remote gelesen und am Repo gespeichert, ein Arbeitsbereich kann also Repos von allen dreien halten. Alles andere wird abgelehnt. Der Ordnerbrowser, aus dem du wählst, listet das Dateisystem des Server-Hosts, begrenzt auf die Zulassungsliste --repo-roots des Servers (standardmäßig das Home-Verzeichnis des Serverbenutzers).

Ein Repository aus einem Arbeitsbereich zu entfernen löscht die Zeile vollständig und kaskadiert seine Code-Symbole, Kanten, Dateien, Index-Checkpoints und Freigaben je Mitglied. Der Checkout auf der Festplatte bleibt unberührt.

Der Code-Graph lebt in derselben Datei, geschlüsselt nach repoId, weil verschiedene Arbeitsbereiche dasselbe Repository auf verschiedenen Branches mit verschiedenem Code haben können.

Die Isolationsinvariante

Datenlecks über Arbeitsbereiche hinweg gelten als Bugs. Die Isolation ist strukturell und wird auf mehreren Ebenen durchgesetzt:

Datenbankschicht. Jeder Arbeitsbereich hat seine eigene SQLite-Datei, ausgegeben von WorkspaceDatabaseManager.of(workspaceId). Eine Arbeitsbereichsdatenbank deklariert weder users noch workspaces noch die Tabellen irgendeines anderen Arbeitsbereichs, sodass ein arbeitsbereichsübergreifendes Lesen kein Bug ist, den du schreiben kannst — es kompiliert nicht. Repositories lösen ihr DAO je Aufruf auf, statt eines zu cachen, und weil jede Repository-Methode ein verpflichtendes workspaceId nimmt, lässt sich der Arbeitsbereich nie erschließen und nie vorbelegen.
Die Arbeitsbereichs-ID ist ein Pfadsegment. Weil die ID zu einem Verzeichnisnamen wird, muss sie einem sicheren Muster aus einem einzigen Segment entsprechen (alphanumerischer Anfang, danach Alphanumerisches, Punkte, Unterstriche, Bindestriche; kein ..). IDs sind im ganzen Produkt UUIDs. Alles andere wirft, statt bereinigt zu werden — das ist der Schutz vor Path Traversal, und er scheitert laut, statt die Daten eines Arbeitsbereichs auf einen Pfad zu schreiben, den jemand anders gewählt hat.
Verteidigung in der Tiefe. Die Spalten workspaceId sind noch da und werden noch geschrieben. Innerhalb einer Datei sind sie redundant, sie halten die Sync-Feed-Trigger, die FTS-Indizes und die bestehenden Zeilenformen unverändert, und sie machen eine Datei selbstbeschreibend, wenn du sie für sich betrachtest — genau darauf stützen sich Export und Import.
Domänenschicht. Dienste, die Entitäten anhand der ID verändern, prüfen entity.workspaceId == workspaceId an einem einzigen Engpass, bevor sie fortfahren, und werfen bei Abweichung WorkspaceMismatchException — das laute Scheitern für eine ID, die aus dem falschen Kontext kam. Laut zu verweigern zählt: ein stilles No-op versteckt den Bug, und fortzufahren gibt die Daten preis.
RPC-Schicht. Der Repo-RPC-Dispatcher ist der Engpass. Jede arbeitsbereichsbezogene Operation muss workspace_id in ihren eigenen Argumenten tragen — es gibt keinen „aktuellen Arbeitsbereich“ je Sitzung, über den etwas lecken könnte, und eine unbekannte ID wird als nicht gefunden abgelehnt, bevor irgendetwas eine Datenbank öffnet, sodass eine falsche ID keine Geister-workspace.db anlegen kann. Wirklich globale Operationen (der Newsfeed, die Fleet-Warteschlange) erklären sich als ohne Geltungsbereich, als ausdrückliche, geprüfte Entscheidung. MCP-Tools folgen derselben Regel: jedes Tool, das arbeitsbereichsbezogene Daten berührt, verlangt workspace_id.
Arbeitsbereichsübergreifendes Fan-out ist aufzählbar. Eine Frage über mehrere Arbeitsbereiche zu beantworten heißt, mehrere Datenbanken zu öffnen. Dieses Fan-out sitzt in einem Helfer, CrossWorkspaceQueries, sodass die vollständige Liste dessen, was die Grenze berechtigt überschreitet, in den Aufrufstellen einer Datei steht, statt sich hinter Doc-Kommentaren zu verteilen. Diese Aufrufstellen sind: serverweite Aggregation, Reconciler beim Start, Aufräumläufe für Aufbewahrung und GC, Sicherung, Ereignis-Router — und die Mitgliedschaftssuche unten.
Zugriff nur über die ID reicht nicht. Eine Entität über ihre UUID nachzuschlagen beweist nicht, dass sie zum Arbeitsbereich des Aufrufers gehört. Die Dateiaufteilung macht die falsche Datei unerreichbar; die Prüfung in der Domänenschicht fängt eine falsche ID ab, die durch eine legitime Datei ankommt.

Die Mitgliedschaft gewährt den Zugriff, nicht der Kopplungsschlüssel

Zugangsdaten eines Geräts authentifizieren ein Gerät. Im Arbeitsbereich berechtigen sie zu nichts. Jede arbeitsbereichsbezogene Operation löst die Mitgliedschaftsrolle des Aufrufers auf und setzt eine Untergrenze durch, die sich aus der Art der Operation ergibt — Lesen braucht guest, eine Mutation braucht member, eine zerstörende Operation braucht admin — und Operationen, die Repo-Inhalt zeigen, prüfen zusätzlich die Freigabe des Aufrufers für dieses Repo. Ein gültiger Kopplungsschlüssel ohne Mitgliedschaft erhält Not a member of this workspace.

Für die Isolation hat das eine saubere Folge: die Mitgliedschaftszeilen liegen in der eigenen Datei des Arbeitsbereichs, „Wer ist in diesem Arbeitsbereich?“ ist damit ein gewöhnliches, begrenztes Lesen. Die umgekehrte Frage — „in welchen Arbeitsbereichen bin ich?“ — verteilt sich schon der Definition nach über mehrere Dateien, sie ist deshalb eines der wenigen erlaubten Fan-outs von CrossWorkspaceQueries, und genau das führt die Arbeitsbereichsauswahl aus, bevor irgendein Arbeitsbereich gewählt ist.

Siehe Multiplayer für die Rollenleiter und die Repo-Freigaben.

Die globale Registry

Nicht alles ist arbeitsbereichsbezogen. Eine zweite Datenbank, <dataDir>/global.db, hält, was wirklich serverweit ist:

die Registry der Arbeitsbereiche, damit der Umschalter jeden Arbeitsbereich auflisten kann, ohne eine einzige Arbeitsbereichsdatei zu öffnen — und damit Name, Logo, Eigentümer, manuelle Reihenfolge und die Markierung für das weiche Löschen außerhalb der Datei leben, die sie beschreiben;
Identität: Benutzer, Präferenzen und gekoppelte Geräte, weil ein Mensch über alle Arbeitsbereiche hinweg ein Benutzer ist und ein gekoppeltes Gerät das Löschen eines Arbeitsbereichs übersteht;
die Fleet-Warteschlange (Worker, Jobs, Placement-Log), deren Scheduler bei jedem Tick die ganze Warteschlange gegen jeden Worker abgleicht;
der Newsfeed, der pro Benutzer gilt (nicht pro Arbeitsbereich) — ein Feed, den du hinzufügst, folgt dir in jeden Arbeitsbereich;
workspace_routes, der Index vor der Authentifizierung, der „Welcher Arbeitsbereich besitzt diesen Schlüssel?“ für Einstiegspunkte beantwortet, die mit nichts als einem Geheimnis oder einer opaken ID ankommen (ein Einladungs-Hash, ein Webhook-Token, ein Deep Link) und ohne Arbeitsbereich. Ein Fehltreffer dort ist ein Nicht-gefunden; einen Scan als Rückfall gibt es absichtlich nicht;
installationsweite Einstellungen und Identität: die Installations-ID, Einstellungen auf Host-Ebene, SSO-Verbindungen und verwaltete Aktionsrichtlinien (eine installationsweite Klammer, die Schutzregeln eines Arbeitsbereichs nur verschärfen kann).

Der Start öffnet nur diese Datei. Arbeitsbereichsdateien öffnen sich erst beim ersten Zugriff, sodass der Startaufwand flach bleibt, egal wie viel Verlauf die Arbeitsbereiche ansammeln, und das quick_check je Datei beim ersten Benutzen anfällt, nicht auf dem Weg zum Bereit-Banner.

Eine Arbeitsbereichsdatei trägt nur ein einzeiliges workspace_meta zur Selbstidentifikation (ihre ID, die Installation, die sie angelegt hat, die Schemaversion, mit der sie angelegt wurde, wann). Alles Beschreibende über einen Arbeitsbereich steht in der Registry.

Einen Arbeitsbereich anlegen

Einen Arbeitsbereich anzulegen fügt mehr ein als eine Registry-Zeile. In einem Vorgang trägt der Server den anlegenden Benutzer als ownerUserId ein, schreibt die Mitgliedschaft dieses Benutzers in der Eigentümerrolle und veröffentlicht ein Domain-Ereignis WorkspaceCreated. Zuhörer dieses Ereignisses legen dann idempotent und im Hintergrund an:

einen CEO-Agenten plus vier Spezialisten — qa, architect, engineer, librarian —, wobei die Spezialisten an den CEO berichten;
die eingebauten Pipeline-Vorlagen und ihre Trigger (Ereignis- und manuelle Trigger werden aktiv ausgeliefert; geplante sind Opt-in, außer dem täglichen Worktree-GC-Sweep);
die Eval-Suiten für den Einstieg.

Das geschieht für jeden Arbeitsbereich, nicht nur für den ersten. Die angelegten Agenten entstehen ohne Adapter, sie laufen also auf Control Center (built-in) mit dem Standardmodell von Anthropic (claude-opus-4-8, sofern du kein anderes festlegst), bis du je Agent unter Einstellungen → Arbeitsbereich → Agenten einen Adapter und ein Modell setzt. Siehe Das Agentenmodell.

Das Schreiben der Eigentümer-Mitgliedschaft wiegt mehr, als es aussieht: ohne es hätte der frisch angelegte Arbeitsbereich keine Mitglieder, und jeder folgende arbeitsbereichsbezogene Aufruf des Anlegenden würde abgelehnt.

Löschen, Exportieren, Importieren

Einen Arbeitsbereich zu löschen markiert die Registry-Zeile und hebt die Verknüpfung des Verzeichnisses auf. Der Arbeitsbereich verschwindet aus jeder Liste und jeder Suche. Die Registry-Zeile bleibt (weich gelöscht), damit die ID für Sicherung und Wartung noch bekannt ist, aber workspace.delete verwirft das Verzeichnis dieses Arbeitsbereichs sofort — Datenbank, Worktrees, Agentendateien und den Rest — über WorkspaceDatabaseManager.dropAndClose. Nur der Eigentümer des Arbeitsbereichs kann ihn löschen.

Weil ein Arbeitsbereich eine Datei ist, ist das Weitergeben eine Dateioperation und kein tabellenweiser Dump:

workspace.export ist ein einzelnes VACUUM INTO — ein konsistenter, defragmentierter Snapshot unter einer Lesetransaktion, während der Server weiter Anfragen bedient.
workspace.import übernimmt eine solche Datei und ersetzt, was der Ziel-Arbeitsbereich gerade hält. Das eingebettete workspace_meta lässt einen Import „meine eigene Datei, erneut übernommen“ von „eine Datei aus einer anderen Installation“ unterscheiden (Letzteres ist erlaubt, wird aber protokolliert, statt unsichtbar zu bleiben).
server.backupNow schreibt die ganze Installation in ein Verzeichnis mit Zeitstempel, das das laufende Datenverzeichnis spiegelt — manifest.json, global.db und eine <workspaceId>/workspace.db je Arbeitsbereich —, sodass Wiederherstellen Zurückkopieren ist.
server.listBackups liest dieses Verzeichnis zurück, neueste zuerst, mit Größe und Arbeitsbereichsliste jedes Snapshots. Ein Snapshot, dessen Manifest fehlt oder Dateien nennt, die nicht da sind, wird trotzdem gemeldet und als unvollständig gekennzeichnet — ihn zu verstecken ist der Weg, auf dem ein Betreiber glaubt, eine Sicherung zu haben, die er nicht hat.

Die Sicherungsoperationen liegen unter Einstellungen → Server → Sicherung und Wiederherstellung: Jetzt sichern nimmt einen Snapshot der Installation, die Liste zeigt, welche Snapshots vollständig sind, und lässt den Eigentümer der Installation einen nach Bestätigung löschen, und jeder Arbeitsbereich bietet Export und Import. Die eingebaute Pipeline Workspace backup sichert nur die Datenbank dieses Arbeitsbereichs im Wochenrhythmus und löscht ihre eigenen Sicherungen, die älter sind als das konfigurierte Aufbewahrungsalter. Einen Arbeitsbereich aus einem Installations-Snapshot wiederherzustellen heißt, workspace.import auf die <workspaceId>/workspace.db des Snapshots zu richten; eine ganze Installation wiederherzustellen bleibt ein Zurückkopieren des Snapshot-Verzeichnisses bei gestopptem Server.

Was keine von ihnen mitnimmt, ist der Rest des Arbeitsbereichsverzeichnisses. Ein Arbeitsbereich sammelt mehr an als eine Datenbank — eingefügte Bilder, Skill- und Agentendateien, Chat-Zugangsdaten, Worktrees — und Export und Import bewegen die Datei, sodass alles daneben liegen bleibt, wo es ist. Für Zugangsdaten ist das gewollt, für Worktrees entbehrlich; für den Rest ist es eine Grenze, die du kennen musst, und kein Feature. Die vollständige Tabelle steht in Backup, Export und Import.

Eine Sicherung zwischen dem Server und deinem Gerät verschieben

Jede Operation oben spricht in Pfaden auf dem Server, und das ist nur dann eine vollständige Antwort, wenn der Server dein eigener Rechner ist. Drei signierte HTTP-Routen — /backup/workspace, /backup/snapshot und /backup/restore — transportieren die Bytes für jede andere Topologie, auf derselben authentifizierten Bahn, die der Medien-Proxy und der Bildspeicher schon nutzen. Auf der Seite ist das ein Knopf Herunterladen neben jedem Export und jedem Snapshot (du wählst, wo die Datei landet), und Datei auswählen und hochladen, um aus einer Datei wiederherzustellen, die auf dem Rechner liegt, den du gerade benutzt. Der Upload ist der Weg, der funktioniert, wenn der Server nicht dein Rechner ist: workspace.import braucht die Datei schon auf dem Host, und so kommt sie dorthin.

Drei Eigenschaften solltest du kennen:

Ein Download erzeugt eine frische Kopie, und der Server behält nichts davon. Herunterladen heißt nicht „hol die Datei, die der Export-Knopf erzeugt hat“ — er exportiert erneut, streamt das und löscht es. Die Antwort ist no-store mit Accept-Ranges: none aus demselben Grund: ein fortgesetzter Range würde zwei verschiedene Exporte zu einer Datei zusammenfügen, die gültig aussieht und es nicht ist.
Ein Upload wird auf die Festplatte gestreamt, nie gepuffert, an beiden Enden, und die bereitgestellte Kopie wird auf jedem Weg nach draußen gelöscht — auch bei einer Ablehnung. Eine Arbeitsbereichsdatenbank ist kein Screenshot.
Eine Verbindung über das Relay hat keinen HTTP-Origin, deshalb sind die Transfer-Steuerelemente dort deaktiviert, mit einem Hinweis, warum. Alles, was in serverseitigen Pfaden spricht, funktioniert weiter über das Relay; nur die Byte-Bahnen brauchen eine direkte Verbindung.

Mehrere Arbeitsbereiche

Du kannst mehrere Arbeitsbereiche nebeneinander betreiben. Jeder arbeitet für sich: Agenten in einem Arbeitsbereich können Agenten in einem anderen nicht schreiben, können das Gedächtnis eines anderen Arbeitsbereichs nicht lesen und seine Tickets nicht sehen. Die Auflösung des Empfängers bei Nachrichten von Agent zu Agent ist exakt und überschreitet nie einen Arbeitsbereich.

Es gibt kein arbeitsbereichsübergreifendes Dashboard. Die Analyseoberfläche unter /workspaces/:workspaceId/observability abonniert einen begrenzten globalen Feed der jüngsten Läufe und grenzt ihn sofort auf den aktiven Arbeitsbereich ein, sodass du dort immer einen Arbeitsbereich auf einmal siehst. Die einzigen wirklich arbeitsbereichsübergreifenden Oberflächen, die ein Mensch berührt, sind die Arbeitsbereichsauswahl und der Umschalter.

Eine praktische Grenze solltest du kennen: ein Arbeitsbereich, den jemand benutzt, bleibt offen — es gibt kein LRU. Ab 32 davon warnt der Server, statt abzulehnen, weil jede offene Datei ein Hintergrund-Isolate und einen Page-Cache hält. Arbeitsbereichsübergreifendes Fan-out öffnet Dateien vorübergehend und schließt sie danach, wenn nichts anderes sie beansprucht hat.