Homokozószabályzatok konfigurálása

Hogy egy ügynökfutás homokozóba kerül-e, a szerver dönti el, indításkor (--sandbox). A Homokozó engedélyezése kapcsoló és a Háttér választó a Beállítások → Szerver → Diagnosztika és adatvédelem alatt az eszközén tárolt beállítások. A Homokozó kártya hosztészlelése azt jelenti, mit tud becsomagolni a szerver hosztja.

Két vezérlő ér el egy futást, és ez az útmutató mindkettőt tárgyalja: a műveleti szabályok a Beállítások → Munkaterület → Ügynökjogosultságok alatt, amelyek eldöntik, mit pusholhat, nyithat meg vagy érhet el egy ügynök, és a szerver saját --sandbox kapcsolója.

Mi korlátozza az ügynökfutást

Az ügynököt hat dolog köti meg. Az első az operációs rendszer homokozója, és ez az, amelyik feltételes — a másik öt minden hoszton tart.

Határ	Mit tesz
Az operációs rendszer homokozója	Seatbelt macOS-en, bubblewrap Linuxon és WSL2-n. Becsomagolja a Claude Code CLI-t, az ACP-adaptereket és a harness `bash` eszközét. Windowson és `bwrap` és `socat` nélküli Linuxon nincs
A saját worktree-je	Minden beszélgetés kap egy copy-on-write checkoutot. Az eredeti checkout írásmegtagadási útvonalként kerül a futásba, és a homokozó az, ami érvényesíti
Közvetített hitelesítő adatok	A hitelesítőadat-közvetítő futásonkénti környezetet állít ki, és a lebontáskor visszavonja. A benne lévő GitHub-token olvasni tud, pusholni nem: a push a Control Centeren megy át, amely előbb a push-szabályt kérdezi meg
Műveleti korlátok	Minden állapotmódosító eszköz deklarálja a hatásosztályait, és a korlátmotor a hívás lefutása előtt feloldja őket. Egy `prompt`, amelyhez nincs csatlakoztatott jóváhagyó, elutasításra kerül
A környezet megtisztítása	Az ACP és a harness `bash` eszköze szűrt környezetet kap. A Claude Code a `NoSandboxAdapter`-en keresztül a hoszt környezetét örökli
A mód eszközfelülete	Egy csak olvasható mód teljesen eltávolítja a worktree-t módosító eszközöket, és rögzíti a mód saját kimeneti igéjét, hogy így is le tudjon szállítani

Három dolog gyengébb marad, mint amilyennek látszik:

Csak a beépített harness érvényesíti az eszközkaput, a teljesítési szerződéseket és a szerkezeti módszabályokat. A Claude Code adapter nem. A Claude Code különösen --dangerously-skip-permissions kapcsolóval indul, mert egy nem interaktív claude -p egyébként örökre blokkolna a saját kérdésénél — így a Claude saját olvasó, író és szerkesztő hívásait a Control Center sem nem látja, sem nem kapuzza, a bash parancsait pedig csak egy hook ellenőrzi, amely a parancssort olvassa. Ahol a homokozó be van kapcsolva, az a határ körülöttük.
A harness folyamaton belüli fájleszközei (read, write, edit, apply patch, search, find, search_files) a szerverfolyamaton belül futnak, így egyetlen homokozóprofil sem korlátozza őket. Csak a bash eszköz megy át a homokozott parancsfuttatón. Ezeket az eszközöket a saját útvonal-elkülönítésük és a műveleti korlátok szorítják határok közé.
Egy háttérrendszer nélküli hoszton az első sor egyáltalán nem érvényes. Az ACP és a harness bash eszköze a környezet megtisztítására és a parancsszabályzatra esik vissza; a Claude Code a NoSandboxAdapter-en keresztül a hoszt környezetét örökli. A szerver erről az indítási naplójában számol be. Az alábbiakban ellenőrizze a sajátját.

Annak eldöntése, mit pusholhat egy ügynök

A git push, a GitHub, a jegykezelés és a hálózat számára nincs ügynökönkénti kapcsoló. Mindegyik egy műveleti szabály:

Szabály	Beépített alapértelmezett	Mire vonatkozik
Küldés távoli tárolóra	Előbb kérdezzen	Minden `git push` a GitHubra, bármelyik adapterrel
Pull request megnyitása	Előbb kérdezzen	`gh pr create` és a pull request-eszközök
Átnézés vagy összefésülés közzététele	Előbb kérdezzen	`gh pr merge`, `gh pr review`, `gh pr comment`, `gh pr close`
Írás külső követőbe	Előbb kérdezzen	Jegyírás a Control Center eszközein keresztül és `gh issue`
Hálózati hozzáférés	Engedélyezés	Van-e egyáltalán hálózata a homokozónak, és a harness webes eszközei

Nyissa meg a Beállítások → Munkaterület → Ügynökjogosultságok oldalt
Válassza ki a hatókört — Munkaterület, Ügynök vagy Tér —, és a szabály sorában válassza az Engedélyezés, az Előbb kérdezzen vagy a Tiltás lehetőséget

Az ágakra korlátozott push-szabályok, például egy, amely tiltja a main-re irányuló pusht, szintén érvényesek: lásd a Korlátok oldalt.

Ellenőrzőpont: kérje meg az ügynököt, hogy pusholjon egy ágat. Előbb kérdezzen esetén jóváhagyási kérést kap a repóval és a refekkel; Tiltás esetén a git ezt írja ki: ! [remote rejected] <ref> (Control Center policy: …).

Hogyan érik el az egyes szabályok a futást:

A push azzal érvényesül, ami a futás birtokában van. A GitHub-tokenje egy csak olvasásra jogosult GitHub App telepítési token, amely tartalmat olvashat és pull requestekkel dolgozhat. A git-konfigurációja minden GitHub-pusht egy loopback átjáróhoz küld a cc_server-en, amely megkérdezi a szabályt, és csak ezután továbbítja a pusht egy írási tokennel, amelyet az ügynök soha nem lát. Az átjáró csak a worktree saját repójába vagy a munkaterülethez kapcsolt GitHub-repóba továbbít. Ez minden adapterre érvényes.
A shellből indított pull requesteket és issue-kat a parancssor alapján ismeri fel a harness bash eszköze és – egy hookon keresztül – a Claude Code Bash eszköze. Egy ügynök, amely elrejti a parancsot (szkript, eval, közvetlen API-hívás), átjut ezen az ellenőrzésen, a push-átjárón azonban nem.
A jegykezelő kulcsok soha nem kerülnek a homokozóba. Az ügynökök a Control Center MCP eszközein keresztül írnak jegyeket, amelyek a szabályt kérdezik meg.
A hálózat egyszer, a futás indulásakor oldódik fel. A Tiltás kikapcsolja a homokozó hálózatát; az Engedélyezés és az Előbb kérdezzen bekapcsolva hagyja, és Előbb kérdezzen esetén a harness web_fetch és web_search eszköze továbbra is minden hívásnál kérdez. Amíg a hálózat be van kapcsolva, a GitHub mindig szerepel a kimenő engedélylistán.

Ellenőrizze, hogy az ügynökfutásai homokozóba vannak-e zárva

Két dolog dönti el, mindkettő a szerveren: hogy a hoszt kínál-e háttérrendszert, és hogy a --sandbox be van-e kapcsolva. Ebben a sorrendben ellenőrizze őket.

Lépjen a Beállítások → Szerver → Diagnosztika és adatvédelem oldalra
Olvassa el a Homokozó kártyát. A Hoszt adat az a gép, amelyen a cc_server fut, nem az, amelyet éppen néz. A Háttér mező a Natív homokozó (macOS-en Seatbelt, Linuxon és WSL2-n bubblewrap) vagy a Nincs elszigetelés értéket sorolja fel. Az Érvényben adat ennek az eszköznek a beállítása, nem az a becsomagolás, amelyet a szerver ténylegesen használ.
Olvassa el a szerver indítási naplóját. Pontosan az alábbi három sor egyikét írja ki:
- agent sandbox ON a háttérrendszer-megjegyzéssel — a futások be vannak csomagolva
- no OS-native agent sandbox on this host egy telepítési tippel, ahol van ilyen — a futások nincsenek becsomagolva
- agent sandbox DISABLED by --sandbox off — szándékos kikapcsolás

A GET /healthz nem számol be a homokozó állapotáról, így az ellenőrzés az indítási napló.

A homokozó szándékos kikapcsolásához — egy hoszt, ahol a profil rosszul viselkedik, épp ezért létezik a lehetőség — indítsa a szervert --sandbox off kapcsolóval, vagy állítsa be a CC_SERVER_SANDBOX=off értéket. Az alapértelmezés az on, és az on azt jelenti: „használj háttérrendszert, ha van a hoszton”, soha nem azt, hogy „követelj meg egyet”.

Két helyzet soha nem kap natív homokozóbecsomagolást. Windowson a natív felmérés mindig elérhetetlent jelent, és nincs mit telepíteni — az ügynök-kiosztás a none értéket használja. A microvm háttérrendszer különálló (interaktív terminálok és állomások), és a saját futtatókörnyezetén a felmérés kapuzza. Linuxon és WSL2-n a bwrap és a socat egyaránt kell a PATH-ban; nélkülük a felmérés elérhetetlent jelent, és megnevezi a hiányzó csomagokat.

Linuxon/WSL2-n bubblewrap telepítése esetén a standard szabályzat titkosfájl-globjai nem érvényesíthetők azokra a fájlokra, amelyeket az ügynök később hoz létre. Egy ilyen natív futás most inkább megbukik, ahelyett hogy csendben figyelmen kívül hagyná a szabályokat. Egy pozitív indítási felmérés ezért nem garantálja, hogy egy Linuxon történő kiosztás el tud indulni. A --sandbox off szándékos, korlátlan kikapcsolás, nem biztonsági határ helyettesítője.

Tudja, mit tilt már eleve egy mód

A mód térenként tárolódik, és módkészlet rétegként táplálja a korlátfeloldót. A négy mód közül három csak olvasható, és egy csak olvasható mód tizenegy hatásosztályt utasít el eleve:

Mód	Worktree	A készlet által elutasítva
Ügynök (`chat`)	Írható	Semmi — a beépített alapértelmezések érvényesek
Terv	Csak olvasható	Fájl törlése, írás a worktree-n kívül, commit, push, PR megnyitása, közzététel vagy összefésülés, írás külső követőbe, csomag telepítése, folyamat futtatása, a munkaterület szerkezetének módosítása, elszigetelt környezet (állomás) indítása vagy irányítása
Átnézés	Csak olvasható	Ugyanaz a tizenegy. Nem választható ki a felhasználó által — az üzenetszerkesztő csak az Ügynök, a Terv és az Orchestrálás lehetőséget kínálja
Orchestrálás	Csak olvasható	Ugyanaz a tizenegy

A hálózati hozzáférést és a titkok elérését egy csak olvasható mód szándékosan nem utasítja el: épp a kutatás a lényege.

Jóváhagyás kérése, mielőtt egy művelet lefut

A jóváhagyás korlátdöntés, nem homokozóbeállítás.

Lépjen a Beállítások → Munkaterület → Ügynökjogosultságok oldalra
Állítsa a műveletosztályt Előbb kérdezzen értékre a munkaterület, az ügynök vagy a tér hatókörében

Egy Előbb kérdezzen döntés megszakítja a futást, és megkérdezi Önt. Csatlakoztatott jóváhagyó nélkül zárt hibamódban megbukik, és a művelet elutasításra kerül. A teljes feloldási sorrendet lásd: Korlátok konfigurálása.

Hibaelhárítás

Az ügynök nem tud pusholni, és soha nem tiltottam meg

Nézze meg, mit írt ki a git. A Control Center policy: … azt jelenti, hogy egy szabály elutasította a pusht, vagy egy Előbb kérdezzen megválaszolatlan maradt. A … is not linked to this workspace azt jelenti, hogy a push olyan repót céloz, amely sem a worktree sajátja, sem a munkaterülethez kapcsolt. A Control Center has no GitHub credential that can push … azt jelenti, hogy a GitHub App nincs telepítve az adott repóra, és egyetlen tartalék hitelesítő adat sem tudott pusholni: telepítse az alkalmazást a repóra, vagy csatlakoztassa a GitHubot.

A Homokozó kártya nem jelez natív homokozót

Akkor azon a hoszton az ügynökfutások nincsenek Seatbeltbe vagy bubblewrapbe csomagolva, és a fennmaradó határok azok, amije van. Linuxon és WSL2-n telepítse mindkét hiányzó eszközt — sudo apt-get install bubblewrap socat —, és indítsa újra a szervert; az indítási napló ekkor azt írja majd, hogy a homokozó be van kapcsolva. Windowson nincs telepíthető natív háttérrendszer, ezért inkább szigorítsa a korlátokat: lásd Korlátok konfigurálása.

Az ügynök elért egy fájlt a worktree-jén kívül

Hogy melyik eszköz érte el, az dönti el, hogy ez várható-e.

A harness folyamaton belüli fájleszközei (read, write, edit, apply patch, search, find, search_files) a szerverfolyamaton belül futnak, így rájuk egyetlen homokozóprofil sem érvényes — a határukat a saját útvonal-elkülönítésük és a korlátok jelentik. Egy bash parancs vagy a Claude Code CLI viszont be van csomagolva ott, ahol van háttérrendszer, és a regisztrált checkoutjai minden módban írásmegtagadás alá esnek a becsomagoláson belül, a symlink-feloldott írásmódjukkal együtt (macOS-en a /tmp vagy a /var/folders felé vezető útvonal a /private alá oldódik fel, és most már mindkét írásmód tiltva van). Egy háttérrendszer nélküli hoszton ebből semmi nem érvényes. Bármelyik esetben a korlátok eleve elutasíthatják az Írás a worktree-n kívül műveletet.