Konfigurer sandkassepolicyer

Om en agentkjøring er sandkasset, avgjøres på serveren, ved oppstart (--sandbox). Bryteren Slå på sandkasse og velgeren Backend under Innstillinger → Server → Diagnostikk og personvern er innstillinger som lagres på enheten din. Sonderingen av verten i Sandkasse-kortet rapporterer hva serververten kan pakke inn.

To kontroller når fram til en kjøring, og denne guiden dekker begge: handlingsreglene under Innstillinger → Arbeidsområde → Agenttillatelser, som avgjør hva en agent får pushe, åpne eller nå, og serverens eget --sandbox-flagg.

Hva som begrenser en agentkjøring

En agent holdes av seks ting. Den første er OS-sandkassen, og den er den eneste som er betinget — de fem andre holder på alle verter.

Grense	Hva den gjør
OS-sandkassen	Seatbelt på macOS, bubblewrap på Linux og WSL2. Pakker inn Claude Code-CLI-et, ACP-adaptere og harnessets `bash`-verktøy. Finnes ikke på Windows og på Linux uten `bwrap` og `socat`
Sin egen worktree	Hver samtale får sin egen copy-on-write-arbeidskopi. Den opprinnelige arbeidskopien legges inn i kjøringen som en skrivenekt-sti, og det er sandkassen som håndhever den
Formidlet legitimasjon	Legitimasjonsmegleren utsteder et miljø per kjøring og tilbakekaller det ved avslutning. GitHub-tokenet i det kan lese, men ikke pushe: en push går gjennom Control Center, som først spør push-regelen
Tillatelsesregler for handlinger	Hvert muterende verktøy deklarerer effektklassene sine, og vakten løser dem før kallet kjøres. Et `prompt` uten tilkoblet godkjenner nektes
Sanering av miljøet	ACP og harnessets `bash`-verktøy får et filtrert miljø. Claude Code gjennom `NoSandboxAdapter` arver vertens miljø
Modusens verktøyflate	En skrivebeskyttet modus fjerner verktøyene som muterer worktreet, helt, og fester modusens eget utdataverb så den fortsatt kan levere

Tre ting er svakere enn de ser ut:

Bare det innebygde harnesset håndhever verktøyporten, fullføringskontraktene og de strukturelle modusreglene. Claude Code-adapteren gjør det ikke. Nettopp Claude Code startes med --dangerously-skip-permissions, fordi en ikke-interaktiv claude -p ellers ville blokkere for alltid på sin egen prompt — så Claudes egne lese-, skrive- og redigeringskall verken ses eller portes av Control Center, og bash-kommandoene kontrolleres bare av en hook som leser kommandolinjen. Der sandkassen er på, er den grensen rundt dem.
Harnessets prosessinterne filverktøy (read, write, edit, apply patch, search, find, search_files) kjører inne i serverprosessen, så ingen sandkasseprofil begrenser dem. Bare bash-verktøyet går gjennom den sandkasseinnpakkede kommandokjøreren. Disse verktøyene er begrenset av sin egen stibegrensning pluss tillatelsesreglene for handlinger.
På en vert uten backend gjelder den første raden ikke i det hele tatt. ACP og harnessets bash-verktøy faller tilbake på sanering av miljøet pluss kommandopolicyen; Claude Code arver vertens miljø gjennom NoSandboxAdapter. Serveren sier fra om dette i oppstartsloggen. Sjekk din nedenfor.

Avgjør hva en agent får pushe

Det finnes ingen bryter per agent for git push, GitHub, saker eller nettverket. Hver av dem er en handlingsregel:

Regel	Innebygd standard	Hva den dekker
Push til en remote	Spør først	Hver `git push` til GitHub, uansett adapter
Åpne en pull request	Spør først	`gh pr create` og verktøyene for pull requests
Publiser en gjennomgang eller sammenslåing	Spør først	`gh pr merge`, `gh pr review`, `gh pr comment`, `gh pr close`
Skriv til et eksternt oppfølgingssystem	Spør først	Saksskriving gjennom Control Centers verktøy og `gh issue`
Bruk nettverket	Tillat	Om sandkassen har nettverk i det hele tatt, og harnessens nettverktøy

Gå til Innstillinger → Arbeidsområde → Agenttillatelser
Velg omfang — Arbeidsområde, Agent eller Område — og velg Tillat, Spør først eller Nekt på regelens rad

Push-regler som er begrenset til grener, for eksempel en som nekter push til main, gjelder også: se Tillatelsesregler.

Kontrollpunkt: be agenten pushe en gren. Med Spør først får du en godkjenning som oppgir repoet og refs; med Nekt skriver git ut ! [remote rejected] <ref> (Control Center policy: …).

Slik når hver regel kjøringen:

Push håndheves gjennom det kjøringen har. GitHub-tokenet er et installasjonstoken for GitHub App som bare kan lese: det kan lese innhold og jobbe med pull requests. Git-konfigurasjonen sender hver push til GitHub til en loopback-gateway på cc_server, som spør regelen og først da sender pushen videre med et skrivetoken agenten aldri ser. Gatewayen sender bare videre til worktreens eget repo eller til et GitHub-repo som er koblet til arbeidsområdet. Dette gjelder for alle adaptere.
Pull requests og saker fra et skall gjenkjennes på kommandolinjen, i harnessens bash-verktøy og, gjennom en hook, i Claude Codes Bash-verktøy. En agent som skjuler kommandoen (et skript, eval, et direkte API-kall), kommer forbi denne kontrollen, men ikke forbi push-gatewayen.
Saksnøkler legges aldri i sandkassen. Agenter skriver saker gjennom Control Centers MCP-verktøy, som spør regelen.
Nettverket løses opp én gang, når kjøringen starter. Nekt slår av sandkassens nettverk; Tillat og Spør først lar det stå på, og med Spør først spør harnessens web_fetch- og web_search-verktøy fortsatt ved hvert kall. Så lenge nettverket er på, står GitHub alltid på den utgående tillatelseslisten.

Sjekk om agentkjøringene dine er sandkasset

To ting avgjør det, begge på serveren: om verten tilbyr en backend, og om --sandbox er på. Sjekk dem i den rekkefølgen.

Gå til Innstillinger → Server → Diagnostikk og personvern
Les Sandkasse-kortet. Opplysningen Vert er maskinen cc_server kjører på, ikke maskinen du ser på. Feltet Backend viser Innebygd sandkasse (Seatbelt på macOS, bubblewrap på Linux og WSL2) eller Ingen isolasjon. Opplysningen I kraft er denne enhetens innstilling, ikke innpakningen serveren faktisk bruker.
Les oppstartsloggen til serveren. Den skriver ut nøyaktig én av tre linjer:
- agent sandbox ON pluss backend-merknaden — kjøringer pakkes inn
- no OS-native agent sandbox on this host pluss et installasjonstips der det finnes — kjøringer pakkes ikke inn
- agent sandbox DISABLED by --sandbox off — et bevisst valg om å slå den av

GET /healthz rapporterer ikke sandkassetilstand, så oppstartsloggen er sjekken.

For å slå av sandkassen bevisst — en vert der profilen oppfører seg dårlig, er grunnen til at muligheten finnes — starter du serveren med --sandbox off, eller setter CC_SERVER_SANDBOX=off. Standarden er on, og on betyr «bruk en backend hvis verten har én», aldri «krev én».

To situasjoner får aldri en innebygd sandkasseinnpakning. På Windows rapporterer den innebygde sonderingen alltid at den ikke er tilgjengelig, og det finnes ingenting å installere — agentutsending bruker none. microvm-backenden er noe eget (interaktive terminaler og stasjoner) og avhenger av sin egen sondering av kjøretidsmiljøet. På Linux og WSL2 må både bwrap og socat ligge på PATH; uten dem rapporterer sonderingen at den ikke er tilgjengelig, og navngir pakkene som mangler.

På Linux/WSL2 med bubblewrap installert kan standardpolicyens glob-mønstre for hemmelige filer ikke håndheves for filer en agent oppretter senere. En slik innebygd kjøring feiler nå i stedet for å ignorere reglene i stillhet. En positiv sondering ved oppstart garanterer derfor ikke at en Linux-utsending kan starte. --sandbox off er et bevisst valg om å kjøre uten begrensninger, ikke en erstatning for en sikkerhetsgrense.

Vit hva en modus allerede forbyr

Modusen lagres per område og mates inn i regeløseren som laget modusforhåndsvalg. Tre av de fire modusene er skrivebeskyttede, og en skrivebeskyttet modus avviser elleve effektklasser kontant:

Modus	Worktree	Avvises av forhåndsvalget
Agent (`chat`)	Skrivbar	Ingenting — de innebygde standardene gjelder
Plan	Skrivebeskyttet	Sletting av en fil, skriving utenfor worktreet, commit, push, oppretting av en PR, publisering eller sammenslåing, skriving til et eksternt oppfølgingssystem, installasjon av en pakke, oppstart av en prosess, endring av strukturen i arbeidsområdet, start eller styring av et isolert miljø
Gjennomgang	Skrivebeskyttet	De samme elleve. Ikke brukervalgbart — skrivefeltet tilbyr bare Agent, Plan og Orkestrer
Orkestrer	Skrivebeskyttet	De samme elleve

Nettverkstilgang og tilgang til hemmeligheter nektes bevisst ikke av en skrivebeskyttet modus: forskning er hele poenget med en slik modus.

Krev godkjenning før en handling kjøres

Godkjenning er et vedtak i tillatelsesreglene, ikke en sandkasseinnstilling.

Gå til Innstillinger → Arbeidsområde → Agenttillatelser
Sett handlingsklassen til Spør først på omfanget arbeidsområde, agent eller område

Et Spør først-vedtak avbryter kjøringen og spør deg. Uten en tilkoblet godkjenner stenger den ved feil, og handlingen nektes. Se Konfigurer tillatelsesregler for hele løsningsrekkefølgen.

Feilsøking

En agent kan ikke pushe, og jeg nektet det aldri

Les hva git skrev ut. Control Center policy: … betyr at en regel nektet pushen, eller at en Spør først ikke ble besvart. … is not linked to this workspace betyr at pushen sikter mot et repo som verken er worktreens eget eller koblet til arbeidsområdet. Control Center has no GitHub credential that can push … betyr at GitHub App-en ikke er installert på det repoet, og at ingen reservelegitimasjon kunne pushe: installer appen på repoet eller koble til GitHub.

Sandkasse-kortet rapporterer ingen innebygd sandkasse

Da er ikke agentkjøringer på den verten pakket inn av Seatbelt eller bubblewrap, og de gjenværende grensene er det du har. På Linux og WSL2 installerer du begge verktøyene som mangler — sudo apt-get install bubblewrap socat — og starter serveren på nytt; oppstartsloggen skal da si at sandkassen er på. På Windows finnes det ingen innebygd backend å installere, så stram inn tillatelsesreglene i stedet: se Konfigurer tillatelsesregler.

En agent nådde en fil utenfor worktreet

Hvilket verktøy som nådde den, avgjør om dette er forventet.

Harnessets prosessinterne filverktøy (read, write, edit, apply patch, search, find, search_files) kjører i serverprosessen, så ingen sandkasseprofil gjelder for dem — grensen deres er deres egen stibegrensning pluss tillatelsesreglene. En bash-kommando eller Claude Code-CLI-et blir pakket inn der en backend finnes, og de registrerte arbeidskopiene dine er skrivenekt innenfor den innpakningen i hver modus, inkludert stavemåtene deres med symlenker løst opp (på macOS løses en sti nådd gjennom /tmp eller /var/folders opp under /private, og begge stavemåtene nektes nå). På en vert uten backend gjelder ingenting av dette. Uansett kan tillatelsesreglene avvise Skriv utenfor worktree kontant.