Arbeidsområder og isolasjon

Hva er et arbeidsområde?

Et arbeidsområde er den øverste isolerte leietakeren i Control Center. Det samler agenter, repoer, områder, saker, minne, pipelines og medlemmer i én avgrenset kontekst. Alt som skjer inne i et arbeidsområde, blir værende der.

Et typisk arbeidsområde tilsvarer ett prosjekt eller én kodebase. Du kan ha egne arbeidsområder for «api-service», «frontend-v2» og «infrastructure».

Data med arbeidsområdeomfang

Radene til et arbeidsområde ligger i arbeidsområdets egen SQLite-fil, på <dataDir>/<workspaceId>/workspace.db. Hvert arbeidsområde får en mappe i stedet for bare en fil, fordi et arbeidsområde samler mer enn én database — worktrees per samtale, agent- og skill-filene, legitimasjon til chatboten — og å gi det en mappe betyr at alt dette lever og slettes sammen.

Enhet	Omfang
Agenter	Tilhører nøyaktig ett arbeidsområde
Repoer	Registreres i ett arbeidsområde (se nedenfor)
Områder, samtaler og meldinger	Arbeidsområdeomfang
Saker, prosjekter, planer, orkestreringer	Arbeidsområdeomfang
Minnefakta, policyer, domener, tilgangstildelinger	Arbeidsområdeomfang
Pipeline-kjøringer, maler, utløsere	Arbeidsområdeomfang
Pull request-tilstand, gjennomgangsområder, gjennomgangskohorter	Arbeidsområdeomfang
Agentkjøringslogger og arbeidsminne	Arbeidsområdeomfang
Medlemmer, invitasjoner, tildelinger per repo	Arbeidsområdeomfang
Symboler og kanter i kodegrafen	Begrenset av `repoId` i arbeidsområdefilen

De fleste av disse radene har en workspaceId-kolonne; atskilte databasefiler håndhever isolasjonen. Se isolasjonsinvarianten nedenfor.

Repoer har arbeidsområdeomfang; identitet på tvers av arbeidsområder følger stien

Raden til et repo ligger i arbeidsområdets egen databasefil — filen er omfanget, så tabellen har ingen workspaceId-kolonne og ingen koblingstabell.

Du legger til et repo i et arbeidsområde i Innstillinger → Arbeidsområde → Arkiv. Å registrere samme checkout i to arbeidsområder oppretter to uavhengige rader med to id-er; identiteten til et repo på tvers av arbeidsområder følger filsystemstien (eller GitHub-eier/navn), aldri id-en.

Registreringen er streng: stien må ligge inne i et git-worktree, den må ha et origin-remote, og det remote-et må peke på en støttet kodevert (github.com, gitlab.com eller bitbucket.org). Kodeverten leses fra remote-et og lagres på repoet, så ett arbeidsområde kan inneholde repoer fra alle tre. Alt annet avvises. Mappeleseren du velger fra, viser filsystemet til serververten, begrenset til serverens --repo-roots-tillatelsesliste (som som standard er hjemmemappen til serverbrukeren).

Å fjerne et repo fra et arbeidsområde sletter raden fullstendig og kaskaderer kodesymbolene, kantene, filene, indekssjekkpunktene og tildelingene per medlem. Checkout-en på disken berøres ikke.

Kodegrafen ligger i samme fil, med repoId som nøkkel, fordi ulike arbeidsområder kan ha samme repo på ulike grener med ulik kode.

Isolasjonsinvarianten

Datalekker på tvers av arbeidsområder behandles som feil. Isolasjonen er strukturell og håndheves på flere nivåer:

Databaselaget. Hvert arbeidsområde har sin egen SQLite-fil, utlevert av WorkspaceDatabaseManager.of(workspaceId). En arbeidsområdedatabase deklarerer ikke users, workspaces eller tabellene til noe annet arbeidsområde, så en lesing på tvers av arbeidsområder er ikke en feil du kan skrive — den kompilerer ikke. Repoer løser opp DAO-en sin per kall i stedet for å cache én, og fordi hver repo-metode tar en påkrevd workspaceId, kan arbeidsområdet aldri utledes eller settes til en standardverdi.
Arbeidsområde-id-en er et stisegment. Fordi id-en blir et mappenavn, må den samsvare med et trygt mønster for ett enkelt segment (alfanumerisk start, deretter alfanumeriske tegn, punktum, understreker og bindestreker; ingen ..). Id-er er UUID-er overalt i produktet. Alt annet gir en feil i stedet for å bli sanert — det er vernet mot stitraversering, og det feiler høylytt i stedet for å skrive dataene til et arbeidsområde til en sti noen andre har valgt.
Forsvar i dybden. workspaceId-kolonnene er fortsatt der og skrives fortsatt. Overflødige innenfor én fil holder de sync-feed-utløserne, FTS-indeksene og de eksisterende radformene uendret, og de gjør en fil selvbeskrivende når den inspiseres på egen hånd — som er det eksport og import bygger på.
Domenelaget. Tjenester som muterer entiteter etter id, validerer entity.workspaceId == workspaceId på ett enkelt kontrollpunkt før de fortsetter, og kaster WorkspaceMismatchException ved avvik — den høylytte feilen for en id som kom fra feil kontekst. Å avvise høylytt betyr noe: en stille no-op skjuler feilen, og å fortsette lekker data.
RPC-laget. Repo-RPC-dispatchøren er kontrollpunktet. Hver operasjon med arbeidsområdeomfang må ha workspace_id i sine egne argumenter — det finnes ingen «gjeldende arbeidsområde» per økt som kan lekke, og en ukjent id avvises som ikke funnet før noe åpner en database, så en dårlig id kan ikke materialisere en spøkelses-workspace.db. Operasjoner som virkelig er globale (nyhetsstrømmen, flåkekøen) erklærer seg som uten omfang, som et eksplisitt og gjennomgått valg. MCP-verktøy følger samme regel: ethvert verktøy som berører data med arbeidsområdeomfang, krever workspace_id.
Fan-out på tvers av arbeidsområder kan regnes opp. Å svare på et spørsmål om flere arbeidsområder betyr å åpne flere databaser. Den fan-outen er begrenset til én hjelper, CrossWorkspaceQueries, slik at den fullstendige listen over ting som med rette krysser grensen, ligger i kallpunktene til én fil i stedet for å spre seg bak dokumentasjonskommentarer. Disse kallpunktene er: aggregering for hele serveren, avstemmere ved oppstart, opprydding av oppbevaring og GC, sikkerhetskopi, hendelsesrutere — og medlemskapsoppslaget nedenfor.
Tilgang kun via id er ikke nok. Å slå opp en entitet etter UUID-en dens beviser ikke at den tilhører arbeidsområdet til den som spør. Fildelingen gjør feil fil uoppnåelig; valideringen i domenelaget fanger opp en feil id som kommer inn gjennom en legitim fil.

Medlemskap, ikke paringsnøkkelen, gir tilgang

Å holde en enhetslegitimasjon autentiserer en enhet. Den autoriserer ikke noe inne i et arbeidsområde. Hver operasjon med arbeidsområdeomfang løser opp medlemskapsrollen til den som spør, og håndhever en nedre grense utledet fra operasjonens art — lesing krever guest, en mutasjon krever member, en destruktiv operasjon krever admin — og operasjoner som viser repoinndhold, sjekker i tillegg tildelingen den som spør har for det repoet. En gyldig paringsnøkkel uten medlemskap får Not a member of this workspace.

Konsekvensen for isolasjonen er elegant: medlemskapsradene ligger i arbeidsområdets egen fil, så «hvem er i dette arbeidsområdet?» er en helt vanlig lesing med omfang. Det motsatte spørsmålet — «hvilke arbeidsområder er jeg i?» — er per definisjon spredt over flere filer, så det er en av de få godkjente CrossWorkspaceQueries-fan-outene, og det er det arbeidsområdevelgeren kjører før noe arbeidsområde er valgt.

Se Flerbruker og tilstedeværelse for rollestigen og repotildelinger.

Det globale registeret

Ikke alt har arbeidsområdeomfang. En andre database, <dataDir>/global.db, inneholder det som virkelig gjelder hele serveren:

arbeidsområderegisteret, slik at bytteren kan liste opp hvert arbeidsområde uten å åpne én eneste arbeidsområdefil — og slik at navnet, logoen, eieren, den manuelle rekkefølgen og markøren for myk sletting til et arbeidsområde ligger utenfor filen de beskriver;
identitet: brukere, brukerinnstillinger og parede enheter, fordi ett menneske er én bruker på tvers av alle arbeidsområder, og en paret enhet overlever at et arbeidsområde slettes;
flåkekøen (arbeidere, jobber, plasseringslogg), der planleggeren matcher hele køen mot hver arbeider ved hvert tikkeslag;
nyhetsstrømmen, som er per bruker (ikke per arbeidsområde) — legger du til en strøm, følger den deg inn i hvert arbeidsområde;
workspace_routes, indeksen før autentisering som svarer på «hvilket arbeidsområde eier denne nøkkelen?» for inngangspunkter som kommer med ingenting annet enn en hemmelighet eller en ugjennomsiktig id (en invitasjonshash, et webhook-token, en dyp lenke) og ikke noe arbeidsområde. Et bom der gir «ikke funnet»; det finnes bevisst ingen skanning som reserve;
innstillinger og identitet for hele installasjonen: installasjons-id-en, innstillinger på vertsnivå, SSO-tilkoblinger og styrte handlingspolicyer (en innstramming for hele installasjonen som bare kan stramme inn tillatelsesreglene for arbeidsområdet).

Oppstarten åpner bare denne filen. Arbeidsområdefiler åpnes ikke før de berøres første gang, så oppstartskostnaden holder seg flat uansett hvor mye historikk arbeidsområdene samler, og quick_check per fil betales ved første bruk i stedet for underveis fram til banneret som viser at serveren er klar.

En arbeidsområdefil inneholder bare én enkelt rad workspace_meta for selvidentifikasjon (id-en, installasjonen som opprettet den, skjemaversjonen den ble opprettet med, og når). Alt beskrivende om et arbeidsområde ligger i registeret.

Opprette et arbeidsområde

Å opprette et arbeidsområde gjør mer enn å sette inn en registerrad. I én operasjon stempler serveren brukeren som oppretter det, som ownerUserId, registrerer eierrolle-medlemskapet til den brukeren og publiserer en WorkspaceCreated-domenehendelse. Lyttere på den hendelsen forhåndsfyller deretter, idempotent og i bakgrunnen:

en CEO-agent pluss fire spesialister — qa, architect, engineer, librarian — der spesialistene rapporterer til CEO-en;
de innebygde pipeline-malene og utløserne deres (hendelses- og manuelle utløsere er slått på fra start; planlagte er valgfrie, bortsett fra den daglige worktree-GC-oppryddingen);
start-suitene med evals.

Dette skjer for hvert arbeidsområde, ikke bare det første. De forhåndsopprettede agentene opprettes uten adapter, så de kjører på Control Center (built-in) med Anthropics standardmodell (claude-opus-4-8 hvis du ikke låser fast en annen) til du angir en adapter og modell per agent i Innstillinger → Arbeidsområde → Agenter. Se Agentmodellen.

Skrivingen av eier-medlemskapet betyr mer enn det ser ut som: uten den ville det nyopprettede arbeidsområdet ikke ha noen medlemmer, og hvert kall med arbeidsområdeomfang som oppretteren gjør etterpå, ville bli avvist.

Slette, eksportere, importere

Å slette et arbeidsområde markerer registerraden og fjerner koblingen til mappen. Arbeidsområdet forsvinner fra alle lister og oppslag. Registerraden blir stående (mykt slettet), slik at id-en fortsatt er kjent for sikkerhetskopi og vedlikehold, men workspace.delete fjerner umiddelbart mappen til det arbeidsområdet — database, worktrees, agentfiler og resten — via WorkspaceDatabaseManager.dropAndClose. Bare eieren av arbeidsområdet kan slette det.

Fordi ett arbeidsområde er én fil, er det å overlevere et arbeidsområde en filoperasjon og ikke en tabell-for-tabell-dump:

workspace.export er en enkelt VACUUM INTO — et konsistent, defragmentert øyeblikksbilde tatt under en lesetransaksjon mens serveren fortsetter å betjene forespørsler.
workspace.import adopterer en slik fil og erstatter alt mål-arbeidsområdet til enhver tid inneholder. Den innebygde workspace_meta lar en import skille «min egen fil, gjenadoptert» fra «en fil fra en annen installasjon» (det siste er tillatt, men loggføres i stedet for å være usynlig).
server.backupNow tar et øyeblikksbilde av hele installasjonen til en mappe med tidsstempel som speiler den aktive datamappen — manifest.json, global.db og én <workspaceId>/workspace.db per arbeidsområde — så gjenoppretting er å kopiere den tilbake.
server.listBackups leser den mappen tilbake, nyeste først, med størrelsen og arbeidsområdelisten til hvert øyeblikksbilde. Et øyeblikksbilde der manifestet mangler eller navngir filer som ikke finnes, rapporteres likevel, flagget som ufullstendig — å skjule det er hvordan en operatør begynner å tro at de har en sikkerhetskopi de ikke har.

Sikkerhetskopieringen ligger under Innstillinger → Server → Sikkerhetskopi og gjenoppretting: Sikkerhetskopier nå tar et øyeblikksbilde av installasjonen, listen viser hvilke øyeblikksbilder som er komplette og lar installasjonseieren slette ett etter bekreftelse, og hvert arbeidsområde tilbyr eksport og import. Den innebygde pipelinen Workspace backup tar bare databasen til det arbeidsområdet på en ukentlig plan og sletter sine egne sikkerhetskopier som er eldre enn den konfigurerte oppbevaringsalderen. Å gjenopprette et arbeidsområde fra et installasjonsøyeblikksbilde er workspace.import rettet mot øyeblikksbildets <workspaceId>/workspace.db; å gjenopprette en hel installasjon er fortsatt en tilbakekopiering av øyeblikksbildemappen med serveren stoppet.

Det ingen av dem tar med, er resten av arbeidsområdemappen. Et arbeidsområde samler mer enn én database — innlimte bilder, skill- og agentfiler, chatlegitimasjon, worktrees — og eksport og import flytter filen, så alt ved siden av den blir liggende der det er. Det er bevisst for legitimasjon og kan kastes for worktrees; for resten er det en begrensning å kjenne til, ikke en funksjon. Sikkerhetskopireferansen har hele tabellen.

Flytte en sikkerhetskopi mellom serveren og enheten din

Hver operasjon ovenfor snakker om stier på serveren, noe som bare er et fullstendig svar når serveren er din egen maskin. Tre signerte HTTP-ruter — /backup/workspace, /backup/snapshot og /backup/restore — frakter bytene for alle andre topologier, på samme autentiserte bane som medieproxyen og bildelageret allerede bruker. På siden er dette en Last ned-knapp ved siden av hver eksport og hvert øyeblikksbilde (du velger hvor den lander), og Velg en fil og last opp for å gjenopprette fra en fil som ligger på maskinen du bruker. Opplastingen er den som virker når serveren ikke er din maskin: workspace.import trenger at filen allerede ligger på verten, og det er slik den kommer dit.

Tre egenskaper er verdt å kjenne til:

En nedlasting lager en fersk kopi, og serveren beholder ingenting av den. Å laste ned er ikke «hent filen eksportknappen lagde» — den eksporterer på nytt, strømmer den og sletter den. Svaret er no-store med Accept-Ranges: none av samme grunn: et gjenopptatt intervall ville spleise to forskjellige eksporter til én fil som ser gyldig ut, men ikke er det.
En opplasting strømmes til disk, bufres aldri, i begge ender, og den mellomlagrede kopien slettes på hver vei ut — også ved avvisning. En arbeidsområdedatabase er ikke et skjermbilde.
En reléert tilkobling har ingen HTTP-opprinnelse, så overføringskontrollene er deaktivert der, med en merknad som sier hvorfor. Alt som snakker om stier på serversiden, fortsetter å virke over reléet; bare byte-banene trenger en direkte tilkobling.

Flere arbeidsområder

Du kan kjøre flere arbeidsområder side om side. Hvert av dem fungerer uavhengig: agenter i ett arbeidsområde kan ikke sende meldinger til agenter i et annet, kan ikke lese minnet til et annet arbeidsområde og kan ikke se sakene der. Oppslag av mottakere for agent-til-agent-meldinger er eksakt og krysser aldri et arbeidsområde.

Det finnes ingen dashbord på tvers av arbeidsområder. Analyseflaten på /workspaces/:workspaceId/observability abonnerer på en avgrenset global strøm av nylige kjøringer og begrenser den umiddelbart til det aktive arbeidsområdet, så det du ser der, er ett arbeidsområde om gangen. De eneste flatene som virkelig favner flere arbeidsområder og som et menneske berører, er arbeidsområdevelgeren og bytteren.

Én praktisk begrensning er verdt å kjenne til: et arbeidsområde noen bruker, holder seg åpent — det finnes ingen LRU. Når det er flere enn 32 av dem, advarer serveren i stedet for å avvise, fordi hver åpne fil holder en bakgrunnsisolat og en sidecache. Fan-out på tvers av arbeidsområder åpner filer flyktig og lukker dem etterpå hvis ingenting annet har gjort krav på dem.

Relaterte konsepter

Flerbruker og tilstedeværelse: medlemskap, roller og repotildelinger — tilgangshalvdelen av isolasjonen
Agentmodellen: agenter tilhører nøyaktig ett arbeidsområde
Minne og kunnskap: minne har arbeidsområdeomfang
Arkitektur: hvor databasene ligger i klient/server-delingen
Sikkerhetskopier og gjenopprett: ta et øyeblikksbilde, flytte et arbeidsområde, oppbevare kopier andre steder
Sikkerhetskopi, eksport og import: hver operasjon, rute, manifestfelt og grense
Legg til repoer: registrere en checkout i et arbeidsområde