Konfigurer tillatelsesregler

Denne guiden viser deg hvordan du konfigurerer tillatelsesregler: reglene som avgjør om en agenthandling kjøres, ber om godkjenning først eller avvises.

Tillatelsesreglene dekker de tretten effektklassene som hvert endrende verktøy deklarerer. De håndheves på serversiden i det verktøyet kalles, aldri av en instruks i en prompt.

Sett et vedtak for en handlingsklasse

Gå til Innstillinger → Arbeidsområde → Agenttillatelser
Velg et omfang med den segmenterte kontrollen: Arbeidsområde, Agent (velg deretter agenten) eller Område (velg deretter området)
På raden for handlingsklassen velger du Tillat, Spør først eller Nekt
For å fjerne en regel du har satt, trykker du på tilbakestillingsknappen som vises til slutt på den raden (Tilbakestill til arvet) — vedtaket faller tilbake til det bredere omfanget

Hver rad viser det gjeldende vedtaket som en statusmerkelapp og et merke for hvor det kommer fra: Dette omfanget, Arvet eller Innebygd standard. Matrisen løses på Agent-modus (chat), så Modusforhåndsvalg vises aldri her — bruk «Hva om?»-proben med en skrivebeskyttet modus valgt for å se det laget.

Å skrive en regel krever rollen admin. Å lese matrisen gjør det ikke.

Kontrollpunkt: sett Push til en remote til Nekt på arbeidsområdeomfanget, og kjør deretter «Hva om?»-proben nedenfor på git push origin main. Resultatet viser deny med kilden workspace.

Forstå hvordan et vedtak løses

Løsningen er spesifisitet først, deretter restriktivitet:

Område-regler, deretter agent, deretter arbeidsområde. Det første omfanget med en samsvarende regel bestemmer, og løsningen stopper
Hvis ingen regel samsvarer, gjelder modusforhåndsvalget — en skrivebeskyttet modus (plan, gjennomgang, orkestrering) avviser elleve av de tretten klassene
Hvis modusen ikke har noe å si, gjelder den innebygde standarden

Innenfor ett og samme omfang løses en kommandoregel etter det lengste samsvarende prefikset, og en like spesifikk konflikt løses mest restriktivt — nekt slår spør først, som slår tillat. En handling som deklarerer flere klasser, løses for hver klasse uavhengig og kombineres deretter mest restriktivt.

Et Spør først-vedtak viser én godkjenningsprompt som dekker hver klasse som ble løst til prompt. Hvis ingen godkjenner er tilkoblet, nektes den, både for shell-kommandoer og harness-verktøykall. Det er med vilje: en kjøring uten port er verre enn en avvist kjøring.

Handlingsklasser og innebygde standarder

Handlingsklasse	Innebygd standard
Slett en fil	Spør først
Skriv utenfor worktree	Tillat
Opprett en commit	Tillat
Push til en remote	Spør først
Åpne en pull request	Spør først
Publiser en gjennomgang eller sammenslåing	Spør først
Skriv til et eksternt oppfølgingssystem	Spør først
Bruk nettverket	Tillat
Les en hemmelighet	Tillat
Installer en pakke	Tillat
Kjør en prosess	Tillat
Endre strukturen på arbeidsområdet	Tillat
Styre et isolert miljø (stasjon)	Tillat

Taksonomien er lukket. Et nytt verktøy som leveres uten å deklarere klassene sine, feiler en ratchet-test i CI, så ingenting kommer inn med et stille tomt effektsett.

Test en regel med «Hva om?»-proben

Før du endrer en regel, sjekk hvordan gjeldende policy allerede løser den.

På samme side ruller du ned til Hva om?
Velg en Handling (én av de tretten klassene)
Fyll eventuelt inn Kommando (for eksempel git push origin main), Agent, Område og Modus
Les resultatet: vedtaket, årsaken og Kilde:

Proben kjører den samme løseren som håndhevelsesbanen bruker, mot dine aktive regler, så svaret er nøyaktig. Hvis det overrasker deg, endrer du en regel i matrisen ovenfor og kjører proben igjen.

Still inn autonomien for et område

Bryteren gjelder per agent per område, og den virker sammen med reglene i stedet for å erstatte dem.

Åpne området
Åpne Administrer deltakere fra områdeoverskriften
Under Autonomi på agentens rad velger du et nivå:

Nivå	Effekt
Standard	Ingen innstilling for området — oppfører seg som Handle med godkjenning
Bare foreslå	Hvert portet verktøy nektes blankt, med en melding som ber agenten foreslå handlingen i stedet
Handle med godkjenning	Risikofylte handlinger møter godkjenningsporten, som stenger ved feil
Handle fritt	Forhåndsgodkjenner alt som ikke ble løst til en hard nekt

Bryteren når bare det innebygde harnesset. Claude Code-adapteren kjører sine egne verktøy utenfor denne porten.

Vit hvor tillatelsesreglene ikke rekker

Tabellen Hvor regler håndheves nederst på samme side er app-versjonen av dette: per effektklasse sier den om hver kjører fanger den opp ved policyporten, overlater den til sandkassen, eller ikke kan avskjære den i det hele tatt.

Claude Code-adapteren er bare delvis portet på sine egne verktøykall. Claude Code startes med --dangerously-skip-permissions, så lese-, skrive- og redigeringskallene går aldri gjennom porten. Bash-kommandoene når den gjennom en hook som klassifiserer kommandolinjen, og pushene går gjennom push-gatewayen som for alle agenter. MCP-verktøyflaten den kaller tilbake til, og shell-kommandoen Control Center starter for å kjøre den, er også portet.
En modus’ eget utdataverb (submit_plan, propose_orchestration) er festet og kan aldri nektes — ellers ville en modus strukturelt sett ikke kunne produsere sin eneste leveranse.
Om sandkassen støtter opp under disse reglene, avhenger av verten. Der cc_server finner en backend, pakker den inn Claude Code-CLI-en og harnessets bash-verktøy, så en regel du ikke selv har skrevet, har likevel et OS-gulv under seg. På Windows finnes det ingen, og på Linux eller WSL2 uten bwrap og socat finnes det heller ingen — der er tillatelsesreglene pluss modusens verktøyflate hele håndhevelsen, ikke en ekstra forsvarslinje. Sjekk hvilket tilfelle du er i med Konfigurer sandkassepolicyer.