Sandboxbeleid configureren

Of een agentrun in een sandbox draait, wordt op de server beslist, bij het opstarten (--sandbox). De schakelaar Sandboxing inschakelen en de kiezer Backend onder Instellingen → Server → Diagnose en privacy zijn voorkeuren die op je apparaat zijn opgeslagen. De hostdetectie van de kaart Sandboxing meldt wat de serverhost kan omhullen.

Twee besturingselementen bereiken een run, en deze gids behandelt ze beide: de actieregels onder Instellingen → Werkruimte → Agentmachtigingen, die bepalen wat een agent mag pushen, openen of bereiken, en de eigen --sandbox-vlag van de server.

Wat een agentrun begrenst

Zes dingen begrenzen een agent. Het eerste is de OS-sandbox, en dat is het voorwaardelijke — de andere vijf gelden op elke host.

Grens	Wat het doet
De OS-sandbox	Seatbelt op macOS, bubblewrap op Linux en WSL2. Omhult de Claude Code CLI, ACP-adapters en de `bash`-tool van de harness. Ontbreekt op Windows en op Linux zonder `bwrap` en `socat`
Zijn eigen worktree	Elk gesprek krijgt een copy-on-write-checkout. De oorspronkelijke checkout wordt als deny-write-pad in de run opgenomen, en de sandbox is wat dat afdwingt
Inloggegevens via de broker	De inloggegevensbroker maakt per run een omgeving aan en trekt die weer in bij het afbreken. Het GitHub-token daarin kan lezen maar niet pushen: een push loopt via Control Center, dat eerst de pushregel raadpleegt
Actiebeveiligingen	Elke muterende tool verklaart zijn effectklassen en de beveiliging herleidt ze voordat de aanroep draait. Een `prompt` zonder verbonden goedkeurder wordt geweigerd
Sanering van de omgeving	ACP en de `bash`-tool van de harness krijgen een gefilterde omgeving. Claude Code via `NoSandboxAdapter` erft de omgeving van de host
Het tooloppervlak van de modus	Een alleen-lezen modus haalt de worktree-muterende tools volledig weg en zet het eigen uitvoerwerkwoord van de modus vast, zodat die toch kan opleveren

Drie dingen blijven zwakker dan ze lijken:

Alleen de ingebouwde harness handhaaft de toolpoort, afrondingscontracten en structurele modusregels. De Claude Code-adapter doet dat niet. Claude Code wordt in het bijzonder gestart met --dangerously-skip-permissions, omdat een niet-interactieve claude -p anders voor altijd blijft hangen op zijn eigen prompt — de lees-, schrijf- en bewerkingsaanroepen van Claude zelf worden dus niet door Control Center gezien of door een poort gehaald, en zijn bash-opdrachten controleert alleen een hook die de opdrachtregel leest. Waar de sandbox aan staat, is die de grens eromheen.
De in-process bestandstools van de harness (read, write, edit, apply patch, search, find, search_files) draaien in het serverproces, dus geen enkel sandboxprofiel beperkt ze. Alleen de bash-tool gaat door de gesandboxte opdrachtuitvoerder. Die tools worden begrensd door hun eigen padbeperking plus de actiebeveiligingen.
Op een host zonder backend geldt de eerste rij helemaal niet. ACP en de bash-tool van de harness vallen terug op sanering van de omgeving plus het opdrachtbeleid; Claude Code erft via NoSandboxAdapter de omgeving van de host. De server zegt dat in zijn opstartlog. Controleer het jouwe hieronder.

Bepalen wat een agent mag pushen

Er is geen schakelaar per agent voor git push, GitHub, ticketing of het netwerk. Elk daarvan is een actieregel:

Regel	Standaardwaarde	Wat die dekt
Naar een remote pushen	Eerst vragen	Elke `git push` naar GitHub, welke adapter ook
Een pull request openen	Eerst vragen	`gh pr create` en de pull-requesttools
Een review publiceren of mergen	Eerst vragen	`gh pr merge`, `gh pr review`, `gh pr comment`, `gh pr close`
Naar een externe tracker schrijven	Eerst vragen	Ticketschrijfacties via de tools van Control Center en `gh issue`
Toegang tot het netwerk	Toestaan	Of de sandbox überhaupt een netwerk heeft, en de webtools van de harness

Ga naar Instellingen → Werkruimte → Agentmachtigingen
Kies het bereik — Werkruimte, Agent of Ruimte — en kies op de rij van de regel Toestaan, Eerst vragen of Weigeren

Pushregels die tot branches zijn beperkt, zoals een regel die pushes naar main weigert, gelden ook: zie Beveiligingen.

Controlepunt: vraag de agent een branch te pushen. Bij Eerst vragen krijg je een goedkeuringsverzoek met de repo en de refs; bij Weigeren toont git ! [remote rejected] <ref> (Control Center policy: …).

Hoe elke regel de run bereikt:

Pushen wordt afgedwongen via wat de run bezit. Het GitHub-token is een installatietoken van de GitHub App met alleen leesrechten, dat inhoud kan lezen en met pull requests kan werken. De git-configuratie stuurt elke GitHub-push naar een loopback-gateway op cc_server, die de regel raadpleegt en de push pas daarna doorstuurt met een schrijftoken dat de agent nooit ziet. De gateway stuurt alleen door naar de eigen repo van de worktree of naar een aan de werkruimte gekoppelde GitHub-repo. Dit geldt voor elke adapter.
Pull requests en issues vanuit een shell worden herkend aan de opdrachtregel, in de bash-tool van de harness en, via een hook, in de Bash-tool van Claude Code. Een agent die de opdracht verbergt (een script, eval, een directe API-aanroep) komt langs deze controle, maar niet langs de push-gateway.
Ticketingsleutels komen nooit in de sandbox. Agenten schrijven tickets via de MCP-tools van Control Center, die de regel raadplegen.
Netwerk wordt één keer bepaald, wanneer de run start. Weigeren zet het netwerk van de sandbox uit; Toestaan en Eerst vragen laten het aan, en bij Eerst vragen blijven de tools web_fetch en web_search van de harness bij elke aanroep vragen. Zolang het netwerk aan staat, staat GitHub altijd op de uitgaande allowlist.

Controleren of je agentruns in een sandbox draaien

Twee dingen beslissen dat, beide op de server: of de host een backend biedt en of --sandbox aan staat. Controleer ze in die volgorde.

Ga naar Instellingen → Server → Diagnose en privacy
Lees de kaart Sandboxing. Het gegeven Host is de machine waarop cc_server draait, niet de machine waarnaar je kijkt. Het veld Backend vermeldt Native sandbox (Seatbelt op macOS, bubblewrap op Linux en WSL2) of No isolation. Het gegeven Van kracht is de voorkeur van dit apparaat, niet de omhulling die de server daadwerkelijk gebruikt.
Lees het opstartlog van de server. Het print precies één van drie regels:
- agent sandbox ON plus de backendmelding — runs worden omhuld
- no OS-native agent sandbox on this host plus een installatietip waar die er is — runs worden niet omhuld
- agent sandbox DISABLED by --sandbox off — een bewuste uitschakeling

GET /healthz rapporteert de sandboxstatus niet, dus het opstartlog is de controle.

Om de sandbox bewust uit te zetten — een host waar het profiel zich misdraagt is juist de reden dat die bestaat — start je de server met --sandbox off, of zet je CC_SERVER_SANDBOX=off. De standaardwaarde is on, en on betekent “gebruik een backend als de host er een heeft”, nooit “eis er een”.

Twee situaties krijgen nooit een native sandboxomhulling. Op Windows meldt de native probe altijd dat die niet beschikbaar is en valt er niets te installeren — agent-dispatch gebruikt none. De backend microvm staat apart (interactieve terminals en rigs) en hangt via de probe af van zijn eigen runtime. Op Linux en WSL2 moeten zowel bwrap als socat op het PATH staan; zonder die rapporteert de probe niet beschikbaar en noemt hij de ontbrekende pakketten.

Op Linux/WSL2 met bubblewrap geïnstalleerd kunnen de globs voor geheime bestanden uit het standaardbeleid niet worden afgedwongen voor bestanden die een agent later aanmaakt. Zo’n native run mislukt nu in plaats van de regels stil te negeren. Een positieve probe bij het opstarten garandeert dus niet dat een Linux-dispatch kan starten. --sandbox off is een bewuste, onbegrensde uitschakeling, geen vervangende beveiligingsgrens.

Weten wat een modus al verbiedt

De modus wordt per ruimte opgeslagen en voedt de beveiligingsengine als de laag modusvoorinstelling. Drie van de vier modi zijn alleen-lezen, en een alleen-lezen modus weigert elf effectklassen zonder meer:

Modus	Worktree	Geweigerd door de voorinstelling
Agent (`chat`)	Beschrijfbaar	Niets — de ingebouwde standaardwaarden gelden
Plan	Alleen-lezen	Een bestand verwijderen, buiten de worktree schrijven, een commit maken, pushen, een pull request openen, publiceren of mergen, naar een externe tracker schrijven, een pakket installeren, een proces uitvoeren, de werkruimtestructuur wijzigen, een omhulling starten of aansturen
Review	Alleen-lezen	Dezelfde elf. Niet door de gebruiker te selecteren — de composer biedt alleen Agent, Plan en Orkestratie
Orkestratie	Alleen-lezen	Dezelfde elf

Netwerktoegang en toegang tot secrets worden door een alleen-lezen modus bewust niet geweigerd: onderzoek is juist het hele doel ervan.

Goedkeuring eisen voordat een actie draait

Goedkeuring is een beslissing van de beveiligingen, niet een sandboxinstelling.

Ga naar Instellingen → Werkruimte → Agentmachtigingen
Zet de actieklasse op Eerst vragen, op het niveau van de werkruimte, de agent of de ruimte

Een beslissing Eerst vragen onderbreekt de run en vraagt het jou. Zonder verbonden goedkeurder valt die gesloten en wordt de actie geweigerd. Zie Beveiligingen configureren voor de volledige bereikresolutie.

Problemen oplossen

Een agent kan niet pushen en ik heb het nooit geweigerd

Lees wat git heeft getoond. Control Center policy: … betekent dat een regel de push heeft geweigerd of dat een Eerst vragen onbeantwoord bleef. … is not linked to this workspace betekent dat de push gericht is op een repo die niet die van de worktree is en ook niet aan de werkruimte is gekoppeld. Control Center has no GitHub credential that can push … betekent dat de GitHub App niet op die repo is geïnstalleerd en dat geen terugvalgegeven kon pushen: installeer de App op die repo of koppel GitHub.

De kaart Sandboxing meldt geen native sandbox

Dan worden agentruns op die host niet door Seatbelt of bubblewrap omhuld en heb je het met de overige grenzen te doen. Installeer op Linux en WSL2 beide ontbrekende tools — sudo apt-get install bubblewrap socat — en herstart de server; het opstartlog zou dan moeten zeggen dat de sandbox aan staat. Op Windows valt er geen native backend te installeren, dus scherp je in plaats daarvan de beveiligingen aan: zie Beveiligingen configureren.

Een agent heeft een bestand buiten zijn worktree bereikt

Welke tool het bestand heeft bereikt, bepaalt of dit verwacht gedrag is.

De in-process bestandstools van de harness (read, write, edit, apply patch, search, find, search_files) draaien in het serverproces, dus op hen is geen sandboxprofiel van toepassing — hun grens is hun eigen padbeperking plus de beveiligingen. Een bash-opdracht of de Claude Code CLI wordt wel omhuld waar een backend bestaat, en je geregistreerde checkouts staan binnen die omhulling in elke modus op deny-write, inclusief hun via symlinks herleide spellingen (op macOS herleidt een pad dat via /tmp of /var/folders loopt naar /private, en beide spellingen worden nu geweigerd). Op een host zonder backend geldt niets daarvan. Hoe dan ook kunnen de beveiligingen Buiten de worktree schrijven zonder meer weigeren.