Configurează politicile de sandbox

Dacă o rulare de agent este sandboxată se decide pe server, la pornire (--sandbox). Comutatorul Activează sandboxing-ul și selectorul Backend din Setări → Server → Diagnosticări și confidențialitate sunt preferințe stocate pe dispozitivul tău. Detectarea gazdei din cardul Sandboxing raportează ce poate înveli gazda serverului.

Două controale ajung la o rulare și acest ghid le acoperă pe amândouă: regulile de acțiune din Setări → Spațiu de lucru → Permisiuni agent, care decid ce poate trimite, deschide sau accesa un agent, și flag-ul --sandbox al serverului.

Ce constrânge o rulare de agent

Un agent este ținut de șase lucruri. Primul este sandbox-ul sistemului de operare și este singurul condiționat — celelalte cinci rezistă pe orice gazdă.

Graniță	Ce face
Sandbox-ul sistemului de operare	Seatbelt pe macOS, bubblewrap pe Linux și WSL2. Învelește CLI-ul Claude Code, adaptoarele ACP și instrumentul `bash` al harness-ului. Absent pe Windows și pe Linux fără `bwrap` și `socat`
Propriul worktree	Fiecare conversație primește un checkout copy-on-write. Checkout-ul original este inclus în rulare ca o cale cu scrierea interzisă, iar sandbox-ul este cel care impune asta
Acreditări emise de broker	Brokerul de acreditări emite un mediu per rulare și îl revocă la desființare. Tokenul GitHub din el poate citi, dar nu poate face push: un push trece prin Control Center, care întreabă mai întâi regula de push
Guardrail-uri de acțiuni	Fiecare instrument care modifică starea își declară clasele de efect, iar garda le rezolvă înainte ca apelul să ruleze. Un `prompt` fără niciun aprobator conectat este refuzat
Sanitizarea mediului	ACP și instrumentul `bash` al harness-ului primesc un mediu filtrat. Claude Code prin `NoSandboxAdapter` moștenește mediul gazdei
Suprafața de instrumente a modului	Un mod doar pentru citire elimină de tot instrumentele care modifică worktree-ul și fixează verbul de ieșire al modului, ca să poată livra totuși

Trei lucruri rămân mai slabe decât par:

Doar harness-ul încorporat aplică poarta de instrumente, contractele de finalizare și regulile structurale ale modurilor. Adaptorul Claude Code nu. Claude Code în special este lansat cu --dangerously-skip-permissions, pentru că un claude -p neinteractiv s-ar bloca altfel la nesfârșit pe propriul prompt — așa că apelurile lui de citire, scriere și editare nu sunt nici văzute, nici filtrate de Control Center, iar comenzile lui bash sunt verificate doar de un hook care citește linia de comandă. Acolo unde sandbox-ul este pornit, el este granița din jurul lor.
Instrumentele de fișiere în proces ale harness-ului (read, write, edit, apply patch, search, find, search_files) rulează în interiorul procesului serverului, așa că niciun profil de sandbox nu le constrânge. Doar instrumentul bash trece prin executorul de comenzi sandboxat. Acele instrumente sunt limitate de propria confinare a căilor plus guardrail-urile de acțiuni.
Pe o gazdă fără backend, primul rând nu se aplică deloc. ACP și instrumentul bash al harness-ului se întorc la sanitizarea mediului plus politica de comenzi; Claude Code moștenește mediul gazdei prin NoSandboxAdapter. Serverul spune asta în jurnalul său de pornire. Verifică-l pe al tău mai jos.

Decide ce poate trimite un agent

Nu există un comutator per agent pentru git push, GitHub, ticketing sau rețea. Fiecare este o regulă de acțiune:

Regulă	Implicit încorporat	Ce acoperă
Push către un remote	Întreabă întâi	Fiecare `git push` către GitHub, indiferent de adaptor
Deschide un pull request	Întreabă întâi	`gh pr create` și instrumentele de pull request
Publică o revizuire sau o fuziune	Întreabă întâi	`gh pr merge`, `gh pr review`, `gh pr comment`, `gh pr close`
Scrie într-un tracker extern	Întreabă întâi	Scrieri de tichete prin instrumentele Control Center și `gh issue`
Accesează rețeaua	Permite	Dacă sandbox-ul are rețea, și instrumentele web ale harness-ului

Mergi la Setări → Spațiu de lucru → Permisiuni agent
Alege domeniul de aplicare — Spațiu de lucru, Agent sau Spațiu — și, pe rândul regulii, alege Permite, Întreabă întâi sau Refuză

Se aplică și regulile de push limitate la ramuri, cum ar fi una care refuză push-ul pe main: vezi Guardrail-uri.

Punct de control: cere-i agentului să facă push unei ramuri. Cu Întreabă întâi primești o aprobare care numește depozitul și ref-urile; cu Refuză, git afișează ! [remote rejected] <ref> (Control Center policy: …).

Cum ajunge fiecare regulă la rulare:

Push-ul este impus prin ce deține rularea. Tokenul ei GitHub este un token de instalare GitHub App doar pentru citire, care poate citi conținut și lucra cu pull request-uri. Configurația ei git trimite fiecare push către GitHub unui gateway de loopback pe cc_server, care întreabă regula și abia apoi transmite push-ul cu un token de scriere pe care agentul nu îl vede niciodată. Gateway-ul transmite doar către depozitul propriu al worktree-ului sau către un depozit GitHub legat de spațiul de lucru. Asta e valabil pentru orice adaptor.
Pull request-urile și issue-urile dintr-un shell sunt recunoscute după linia de comandă, în instrumentul bash al harness-ului și, printr-un hook, în instrumentul Bash al Claude Code. Un agent care ascunde comanda (un script, eval, un apel direct la API) trece de această verificare, dar nu de gateway-ul de push.
Cheile de ticketing nu sunt puse niciodată în sandbox. Agenții scriu tichete prin instrumentele MCP ale Control Center, care întreabă regula.
Rețeaua este rezolvată o singură dată, când pornește rularea. Refuză oprește rețeaua sandbox-ului; Permite și Întreabă întâi o lasă pornită, iar cu Întreabă întâi instrumentele web_fetch și web_search ale harness-ului întreabă în continuare la fiecare apel. Cât timp rețeaua este pornită, GitHub este mereu pe lista de permisiuni de ieșire.

Verifică dacă rulările agenților tăi sunt sandboxate

Două lucruri decid asta, ambele pe server: dacă gazda oferă un backend și dacă --sandbox este pornit. Verifică-le în această ordine.

Mergi la Setări → Server → Diagnosticări și confidențialitate
Citește cardul Sandboxing. Faptul Gazdă este mașina pe care rulează cc_server, nu mașina la care te uiți. Câmpul Backend listează Sandbox nativ (Seatbelt pe macOS, bubblewrap pe Linux și WSL2) sau Fără izolare. Faptul În vigoare este preferința acestui dispozitiv, nu învelișul pe care îl folosește de fapt serverul.
Citește jurnalul de pornire al serverului. Afișează exact una dintre trei linii:
- agent sandbox ON plus nota despre backend — rulările sunt învelite
- no OS-native agent sandbox on this host plus un indiciu de instalare acolo unde există — rulările nu sunt învelite
- agent sandbox DISABLED by --sandbox off — o renunțare deliberată

GET /healthz nu raportează starea sandbox-ului, așa că jurnalul de pornire este verificarea.

Ca să oprești sandbox-ul în mod deliberat — o gazdă pe care profilul se comportă prost este motivul pentru care această opțiune există — pornește serverul cu --sandbox off sau setează CC_SERVER_SANDBOX=off. Implicitul este on, iar on înseamnă „folosește un backend dacă gazda are unul”, niciodată „cere unul”.

Două situații nu primesc niciodată un înveliș de sandbox nativ. Pe Windows sonda nativă raportează întotdeauna indisponibil și nu există nimic de instalat — trimiterea agenților folosește none. Backendul microvm este separat (terminale interactive și stații) și este condiționat de sondă pe propriul său runtime. Pe Linux și WSL2, atât bwrap, cât și socat trebuie să fie în PATH; fără ele, sonda raportează indisponibil și numește pachetele lipsă.

Pe Linux/WSL2 cu bubblewrap instalat, globurile de fișiere secrete ale politicii standard nu pot fi aplicate pentru fișierele pe care un agent le creează ulterior. O astfel de rulare nativă eșuează acum, în loc să ignore în silențiu regulile. O sondă de pornire pozitivă nu garantează așadar că o trimitere pe Linux poate porni. --sandbox off este o renunțare deliberată la confinare, nu o graniță de securitate substitutivă.

Află ce interzice deja un mod

Modul este stocat per spațiu și alimentează rezolvitorul de guardrail-uri ca strat de presetare de mod. Trei dintre cele patru moduri sunt doar pentru citire, iar un mod doar pentru citire refuză categoric unsprezece clase de efect:

Mod	Worktree	Refuzate de presetare
Agent (`chat`)	Inscriptibil	Nimic — se aplică impliciturile încorporate
Plan	Doar pentru citire	Șterge un fișier, scrie în afara worktree-ului, creează un commit, push către un remote, deschide un pull request, publică o revizuire sau o fuziune, scrie într-un tracker extern, instalează un pachet, rulează un proces, modifică structura spațiului de lucru, conduce un mediu izolat (stație)
Revizuire	Doar pentru citire	Aceleași unsprezece. Nu poate fi selectat de utilizator — zona de compunere oferă doar Agent, Plan și Orchestrează
Orchestrează	Doar pentru citire	Aceleași unsprezece

Accesul la rețea și accesul la secrete nu sunt refuzate în mod deliberat de un mod doar pentru citire: cercetarea este tocmai rostul unui astfel de mod.

Cere aprobare înainte ca o acțiune să ruleze

Aprobarea este o decizie de guardrail, nu o setare de sandbox.

Mergi la Setări → Spațiu de lucru → Permisiuni agent
Setează clasa de acțiune pe Întreabă întâi la domeniul spațiu de lucru, agent sau spațiu

O decizie Întreabă întâi întrerupe rularea și te întreabă. Fără niciun aprobator conectat, eșuează închis și acțiunea este refuzată. Vezi Configurează guardrail-urile pentru ordinea completă de rezolvare.

Depanare

Un agent nu poate face push și nu am refuzat niciodată asta

Citește ce a afișat git. Control Center policy: … înseamnă că o regulă a refuzat push-ul sau că un Întreabă întâi a rămas fără răspuns. … is not linked to this workspace înseamnă că push-ul țintește un depozit care nu este nici cel al worktree-ului, nici legat de spațiul de lucru. Control Center has no GitHub credential that can push … înseamnă că GitHub App nu este instalat pe acel depozit și nicio acreditare de rezervă nu a putut face push: instalează aplicația pe depozit sau conectează GitHub.

Cardul Sandboxing nu raportează niciun sandbox nativ

Atunci rulările de agent de pe acea gazdă nu sunt învelite de Seatbelt sau bubblewrap, iar granițele rămase sunt tot ce ai. Pe Linux și WSL2, instalează ambele instrumente lipsă — sudo apt-get install bubblewrap socat — și repornește serverul; jurnalul de pornire ar trebui să spună atunci că sandbox-ul este pornit. Pe Windows nu există niciun backend nativ de instalat, așa că strânge în schimb guardrail-urile: vezi Configurează guardrail-urile.

Un agent a ajuns la un fișier din afara worktree-ului său

Ce instrument a ajuns la el decide dacă asta este de așteptat.

Instrumentele de fișiere în proces ale harness-ului (read, write, edit, apply patch, search, find, search_files) rulează în procesul serverului, așa că nu li se aplică niciun profil de sandbox — limita lor este propria confinare a căilor plus guardrail-urile. O comandă bash sau CLI-ul Claude Code este învelit acolo unde există un backend, iar checkout-urile tale înregistrate au scrierea interzisă în interiorul acelui înveliș în orice mod, inclusiv grafia lor rezolvată prin symlink (pe macOS, o cale accesată prin /tmp sau /var/folders se rezolvă sub /private, iar acum ambele grafii sunt interzise). Pe o gazdă fără backend, nimic din toate acestea nu se aplică. În orice caz, guardrail-urile pot refuza categoric Scrie în afara worktree-ului.