Konfigurera sandlådepolicyer

Om en agentkörning är sandlådad avgörs på servern, vid start (--sandbox). Växeln Aktivera sandlåda och väljaren Backend under Inställningar → Server → Diagnostik och integritet är inställningar som lagras på din enhet. Värdidentifieringen i kortet Sandlåda rapporterar vad servervärden kan linda in.

Två kontroller når en körning och den här guiden tar upp båda: åtgärdsreglerna under Inställningar → Arbetsyta → Agentbehörigheter, som avgör vad en agent får pusha, öppna eller nå, och serverns egen flagga --sandbox.

Vad som begränsar en agentkörning

En agentkörning hålls tillbaka av sex saker. Den första är OS-sandlådan och det är den enda som är villkorlig – de övriga fem gäller på varje värd.

Gräns	Vad den gör
OS-sandlådan	Seatbelt på macOS, bubblewrap på Linux och WSL2. Lindar in Claude Code-CLI:n, ACP-adaptrar och harnessens `bash`-verktyg. Saknas på Windows och på Linux utan `bwrap` och `socat`
Sin egen worktree	Varje samtal får en copy-on-write-utcheckning. Den ursprungliga utcheckningen viks in i körningen som en skrivnekad sökväg och det är sandlådan som verkställer det
Mäklade inloggningsuppgifter	Mäklaren för inloggningsuppgifter präglar en miljö per körning och återkallar den vid nedrivning. Dess GitHub-token kan läsa men inte pusha: en push går genom Control Center, som först frågar pushregeln
Åtgärdsräcken	Varje muterande verktyg deklarerar sina effektklasser och grinden löser dem innan anropet körs. En `prompt` utan ansluten godkännare nekas
Miljösanering	ACP och harnessens `bash`-verktyg får en filtrerad miljö. Claude Code via `NoSandboxAdapter` ärver värdmiljön
Lägets verktygsyta	Ett skrivskyddat läge tar bort de worktree-muterande verktygen helt och låser lägets eget utdataverb så att det fortfarande kan leverera

Tre saker är svagare än de ser ut:

Bara den inbyggda harnessen verkställer verktygsgrinden, slutförandekontrakten och de strukturella lägesreglerna. Claude Code-adaptern gör det inte. Särskilt Claude Code startas med --dangerously-skip-permissions, eftersom en icke-interaktiv claude -p annars skulle blockera för evigt på sin egen prompt – så Claudes egna anrop för läsning, skrivning och redigering varken ses eller grindas av Control Center, och dess bash-kommandon kontrolleras bara av en hook som läser kommandoraden. Där sandlådan är på är den gränsen runt dem.
Harnessens filverktyg i processen (read, write, edit, apply patch, search, find, search_files) körs inuti serverprocessen, så ingen sandlådeprofil begränsar dem. Bara verktyget bash går genom den sandlådade kommandoköraren. De verktygen begränsas av sin egen sökvägsbegränsning plus åtgärdsräckena.
På en värd utan backend gäller den första raden inte alls. ACP och harnessens bash-verktyg faller tillbaka på miljösanering plus kommandopolicyn; Claude Code ärver värdmiljön via NoSandboxAdapter. Servern säger det i sin startlogg. Kontrollera din nedan.

Avgör vad en agent får pusha

Det finns ingen växel per agent för git push, GitHub, ärenden eller nätverket. Var och en är en åtgärdsregel:

Regel	Inbyggd standard	Vad den täcker
Pusha till en remote	Fråga först	Varje `git push` till GitHub, oavsett adapter
Öppna en pull request	Fråga först	`gh pr create` och verktygen för pull requests
Publicera en granskning eller sammanslagning	Fråga först	`gh pr merge`, `gh pr review`, `gh pr comment`, `gh pr close`
Skriv till ett externt ärendesystem	Fråga först	Ärendeskrivningar via Control Centers verktyg och `gh issue`
Använd nätverket	Tillåt	Om sandlådan har något nätverk alls, och harnessens webbverktyg

Gå till Inställningar → Arbetsyta → Agentbehörigheter
Välj omfång — Arbetsyta, Agent eller Yta — och välj Tillåt, Fråga först eller Neka på regelns rad

Pushregler som är begränsade till grenar, till exempel en som nekar push till main, gäller också: se Räcken.

Kontrollpunkt: be agenten pusha en gren. Med Fråga först får du ett godkännande som anger repot och refs; med Neka skriver git ut ! [remote rejected] <ref> (Control Center policy: …).

Så når varje regel körningen:

Push framtvingas genom vad körningen har. Dess GitHub-token är en installationstoken för GitHub-appen som bara kan läsa: den kan läsa innehåll och arbeta med pull requests. Dess git-konfiguration skickar varje push till GitHub till en loopback-gateway på cc_server, som frågar regeln och först därefter skickar vidare pushen med en skrivtoken som agenten aldrig ser. Gatewayen skickar bara vidare till worktreens eget repo eller till ett GitHub-repo som är länkat till arbetsytan. Det gäller för alla adaptrar.
Pull requests och issues från ett skal känns igen på kommandoraden, i harnessens bash-verktyg och, via en hook, i Claude Codes Bash-verktyg. En agent som döljer kommandot (ett skript, eval, ett direkt API-anrop) tar sig förbi den här kontrollen, men inte förbi pushgatewayen.
Ärendenycklar läggs aldrig i sandlådan. Agenter skriver ärenden via Control Centers MCP-verktyg, som frågar regeln.
Nätverket löses upp en gång, när körningen startar. Neka stänger av sandlådans nätverk; Tillåt och Fråga först lämnar det på, och med Fråga först frågar harnessens verktyg web_fetch och web_search fortfarande vid varje anrop. Så länge nätverket är på finns GitHub alltid på den utgående allowlisten.

Kontrollera om dina agentkörningar är sandlådade

Två saker avgör det, båda på servern: om värden erbjuder en backend och om --sandbox är på. Kontrollera dem i den ordningen.

Gå till Inställningar → Server → Diagnostik och integritet
Läs kortet Sandlåda. Uppgiften Värd är maskinen som cc_server kör på, inte maskinen du tittar på. Fältet Backend listar Inbyggd sandlåda (Seatbelt på macOS, bubblewrap på Linux och WSL2) eller Ingen isolering. Uppgiften I kraft är den här enhetens inställning, inte den inlindning som servern faktiskt använder.
Läs serverns startlogg. Den skriver ut exakt en av tre rader:
- agent sandbox ON plus backend-anteckningen – körningarna lindas in
- no OS-native agent sandbox on this host plus en installationshänvisning där en sådan finns – körningarna lindas inte in
- agent sandbox DISABLED by --sandbox off – ett medvetet val att stänga av

GET /healthz rapporterar inte sandlådans tillstånd, så startloggen är kontrollen.

För att stänga av sandlådan medvetet – en värd där profilen beter sig illa är anledningen till att den finns – startar du servern med --sandbox off, eller sätter CC_SERVER_SANDBOX=off. Standardvärdet är on och on betyder “använd en backend om värden har en”, aldrig “kräv en”.

Två situationer får aldrig en inbyggd sandlådeinlindning. På Windows rapporterar den inbyggda sonden alltid otillgänglig och det finns inget att installera – agentdispatch använder none. Backenden microvm är separat (interaktiva terminaler och stationer) och sonderas på sin egen runtime. På Linux och WSL2 måste både bwrap och socat finnas i PATH; utan dem rapporterar sonden otillgänglig och namnger de saknade paketen.

På Linux/WSL2 med bubblewrap installerat kan standardpolicyns globmönster för hemliga filer inte verkställas för filer som en agent skapar senare. En sådan inbyggd körning misslyckas nu i stället för att tyst ignorera reglerna. En positiv startsond garanterar därför inte att en Linux-dispatch kan starta. --sandbox off är ett medvetet oinskränkt val att stänga av, inte en ersättande säkerhetsgräns.

Vet vad ett läge redan förbjuder

Läget lagras per yta och matar räckesupplösaren som lagret lägesförinställning. Tre av de fyra lägena är skrivskyddade och ett skrivskyddat läge nekar elva effektklasser direkt:

Läge	Worktree	Nekas av förinställningen
Agent (`chat`)	Skrivbar	Inget – de inbyggda standarderna gäller
Plan	Skrivskyddat	Ta bort en fil, skriva utanför worktreen, skapa en commit, pusha, öppna en PR, publicera eller slå ihop, skriva till ett externt ärendesystem, installera ett paket, köra en process, ändra arbetsytans struktur, starta eller driva en avskild miljö
Granskning	Skrivskyddat	Samma elva. Inte valbart av användaren – composern erbjuder bara Agent, Plan och Orkestrera
Orkestrera	Skrivskyddat	Samma elva

Nätverksåtkomst och hemlighetsåtkomst nekas medvetet inte av ett skrivskyddat läge: forskning är själva poängen med ett sådant.

Kräv godkännande innan en åtgärd körs

Godkännande är ett räckesbeslut, inte en sandlådeinställning.

Gå till Inställningar → Arbetsyta → Agentbehörigheter
Sätt åtgärdsklassen till Fråga först i omfånget arbetsyta, agent eller yta

Ett beslut Fråga först avbryter körningen och frågar dig. Utan ansluten godkännare misslyckas det stängt och åtgärden nekas. Se Konfigurera räcken för hela upplösningsordningen.

Felsökning

En agent kan inte pusha och jag har aldrig nekat den

Läs vad git skrev ut. Control Center policy: … betyder att en regel nekade pushen eller att ett Fråga först blev obesvarat. … is not linked to this workspace betyder att pushen riktas mot ett repo som varken är worktreens eget eller länkat till arbetsytan. Control Center has no GitHub credential that can push … betyder att GitHub-appen inte är installerad på det repot och att ingen fallback-uppgift kunde pusha: installera appen på repot eller anslut GitHub.

Kortet Sandlåda rapporterar ingen inbyggd sandlåda

Då lindas inte agentkörningarna på den värden in av Seatbelt eller bubblewrap och de återstående gränserna är vad du har. På Linux och WSL2 installerar du båda de saknade verktygen – sudo apt-get install bubblewrap socat – och startar om servern; startloggen bör då säga att sandlådan är på. På Windows finns ingen inbyggd backend att installera, så skärp räckena i stället: se Konfigurera räcken.

En agent nådde en fil utanför sin worktree

Vilket verktyg som nådde den avgör om det här är väntat.

Harnessens filverktyg i processen (read, write, edit, apply patch, search, find, search_files) körs i serverprocessen, så ingen sandlådeprofil gäller för dem – deras gräns är deras egen sökvägsbegränsning plus räckena. Ett bash-kommando eller Claude Code-CLI:n lindas in där en backend finns, och dina registrerade utcheckningar är skrivnekade inuti den inlindningen i varje läge, inklusive deras symlänksupplösta stavningar (på macOS löses en sökväg som nås via /tmp eller /var/folders upp under /private och båda stavningarna nekas nu). På en värd utan backend gäller inget av det. Hur som helst kan räckena neka Skriv utanför worktree direkt.