Konfigurera räcken

Den här guiden visar hur du konfigurerar räcken: reglerna som avgör om en agents åtgärd körs, begär godkännande först eller nekas.

Räckena täcker de tretton effektklasser som varje muterande verktyg deklarerar. De verkställs på serversidan i samma stund som verktyget anropas, aldrig genom en instruktion i en prompt.

Ange ett beslut för en åtgärdsklass

Gå till Inställningar → Arbetsyta → Agentbehörigheter
Välj ett omfång med den segmenterade kontrollen: Arbetsyta, Agent (välj sedan agenten) eller Yta (välj sedan ytan)
På raden för åtgärdsklassen väljer du Tillåt, Fråga först eller Neka
För att ta bort en regel du har satt trycker du på återställningsknappen som visas i slutet av den raden (Återställ till ärvt) – beslutet faller tillbaka till det bredare omfånget

Varje rad visar det gällande beslutet som en statustagg och ett märke för var det kommer från: Det här omfånget, Ärvt eller Inbyggd standard. Matrisen löses i läget Agent (chat), så Lägesförinställning visas aldrig här – använd Tänk om-proben med ett skrivskyddat läge valt för att se det lagret.

Att skriva en regel kräver rollen admin. Att läsa matrisen gör det inte.

Kontrollpunkt: sätt Pusha till en remote till Neka i arbetsyteomfånget och kör sedan Tänk om-proben nedan på git push origin main. Resultatet blir deny med källan workspace.

Förstå hur ett beslut löses upp

Upplösningen är specificitet först, sedan restriktivitet:

Yta-regler, sedan agent, sedan arbetsyta. Det första omfånget med en matchande regel avgör och upplösningen stannar
Om ingen regel matchar gäller lägesförinställningen – ett skrivskyddat läge (plan, granskning, orkestrering) nekar elva av de tretton klasserna
Om läget inte har något att säga gäller den inbyggda standarden

Inom ett enskilt omfång löses en kommandoregel genom längsta matchande prefix, och en lika specifik konflikt löses mest restriktivt – neka slår fråga först slår tillåt. En åtgärd som deklarerar flera klasser löser var och en för sig och kombinerar dem sedan mest restriktivt.

Ett Fråga först-beslut visar en enda godkännandeförfrågan som täcker varje klass som löstes till prompt. Utan en ansluten godkännare nekas det, för både shellkommandon och harness-verktygsanrop. Det är avsiktligt: en körning utan grind är värre än en nekad.

Åtgärdsklasser och inbyggda standardvärden

Åtgärdsklass	Inbyggd standard
Ta bort en fil	Fråga först
Skriv utanför worktree	Tillåt
Skapa en commit	Tillåt
Pusha till en remote	Fråga först
Öppna en pull request	Fråga först
Publicera en granskning eller sammanslagning	Fråga först
Skriv till ett externt ärendesystem	Fråga först
Använd nätverket	Tillåt
Läs en hemlighet	Tillåt
Installera ett paket	Tillåt
Kör en process	Tillåt
Ändra arbetsytans struktur	Tillåt
Styr en avskild miljö (station)	Tillåt

Taxonomin är sluten. Ett nytt verktyg som levereras utan att deklarera sina klasser faller ett ratchet-test i CI, så inget anländer med en tyst tom effektmängd.

Testa en regel med Tänk om-proben

Innan du ändrar en regel kontrollerar du hur den aktuella policyn redan löser den.

På samma sida rullar du ned till Tänk om?
Välj en Åtgärd (en av de tretton klasserna)
Fyll valfritt i Kommando (till exempel git push origin main), Agent, Yta och Läge
Läs resultatet: beslutet, orsaken och Källa:

Proben kör samma upplösare som verkställighetsvägen använder, mot dina aktuella regler, så svaret är exakt. Om det överraskar dig ändrar du en regel i matrisen ovan och probar igen.

Ställ in en ytas autonomireglage

Reglaget är per agent och per yta och samverkar med reglerna i stället för att ersätta dem.

Öppna ytan
Öppna Hantera deltagare från ytans sidhuvud
Under Autonomi på agentens rad väljer du en nivå:

Nivå	Effekt
Standard	Ingen ytinställning – beter sig som Agera med godkännande
Bara föreslå	Varje grindat verktyg nekas direkt, med ett meddelande som säger åt agenten att föreslå åtgärden i stället
Agera med godkännande	Riskabla åtgärder hamnar i den fail-closed-godkännandeporten
Agera fritt	Förhandsgodkänner allt som inte löstes till en hård nekning

Reglaget når bara den inbyggda harnessen. Claude Code-adaptern kör sina egna verktyg utanför den här porten.

Vet var räckena inte når

Tabellen Var regler verkställs längst ned på samma sida är appversionen av detta: per effektklass säger den om varje körare fångar den vid policygrinden, lämnar den till sandlådan eller inte kan fånga den alls.

Claude Code-adaptern grindas bara delvis för sina egna verktygsanrop. Claude Code startas med --dangerously-skip-permissions, så dess anrop för läsning, skrivning och redigering passerar aldrig genom skyddet. Dess bash-kommandon når det via en hook som klassificerar kommandoraden, och dess pushar går genom pushgatewayen som alla agenters. Även den MCP-verktygsyta den anropar tillbaka till och det shellkommando som Control Center startar för att lansera den grindas.
Ett läges eget utdataverb (submit_plan, propose_orchestration) är låst och kan aldrig nekas – annars skulle ett läge vara strukturellt oförmöget att producera sin enda leverabel.
Om sandlådan backar upp de här reglerna beror på värden. Där cc_server hittar en backend omsluter den Claude Code-CLI:n och harnessens bash-verktyg, så en regel du inte har skrivit har ändå ett OS-golv under sig. På Windows finns inget och på Linux eller WSL2 utan bwrap och socat finns inget heller – där är räckena plus lägets verktygsyta hela verkställigheten, inte en andra försvarslinje. Kontrollera vilket fall du är i med Konfigurera sandlådepolicyer.