Nastavte politiky sandboxu

Jestli běh agenta běží v sandboxu, rozhoduje se na serveru při startu (--sandbox). Přepínač Zapnout sandboxing a výběr Backend v Nastavení → Server → Diagnostika a soukromí jsou preference uložené na tvém zařízení. Detekce hostitele na kartě Sandboxing hlásí, co umí obalit hostitel serveru.

K běhu sahají dva ovládací prvky a tenhle návod pokrývá oba: pravidla akcí v Nastavení → Pracovní prostor → Oprávnění agentů, která rozhodují, co agent smí pushnout, otevřít nebo kam dosáhnout, a vlastní příznak --sandbox serveru.

Co omezuje běh agenta

Agenta drží šest věcí. První je sandbox operačního systému a ta je podmíněná — zbylých pět drží na každém hostiteli.

Hranice	Co dělá
Sandbox operačního systému	Seatbelt na macOS, bubblewrap na Linuxu a na WSL2. Obalí CLI Claude Code, adaptéry ACP a nástroj `bash` harnessu. Chybí na Windows a na Linuxu bez `bwrap` a `socat`
Vlastní worktree	Každá konverzace dostane copy-on-write checkout. Původní checkout se do běhu vloží jako cesta se zákazem zápisu a vynucuje to sandbox
Pověření od brokera	Broker přihlašovacích údajů vystaví prostředí pro daný běh a při úklidu ho odebere. Token GitHub v něm umí číst, ale ne pushovat: push jde přes Control Center, které se nejdřív zeptá pravidla pro push
Guardraily akcí	Každý mutující nástroj deklaruje své třídy efektů a strážce je vyhodnotí, než se volání spustí. `prompt` bez připojeného schvalovatele se odmítne
Očištění prostředí	ACP a nástroj `bash` harnessu dostanou filtrované prostředí. Claude Code přes `NoSandboxAdapter` dědí prostředí hostitele
Plocha nástrojů režimu	Režim jen pro čtení sundá nástroje, které mění worktree, a připne vlastní výstupní sloveso režimu, aby pořád uměl doručit

Tři věci jsou slabší, než vypadají:

Jen vestavěný harness vynucuje bránu nástrojů, kontrakty dokončení a strukturální pravidla režimu. Adaptér Claude Code ne. Claude Code se navíc spouští s --dangerously-skip-permissions, protože neinteraktivní claude -p by jinak navždy čekalo na vlastní výzvu — takže vlastní volání Claude na čtení, zápis a úpravy Control Center ani nevidí, ani nehlídá a jeho příkazy bash kontroluje jen hook, který čte příkazový řádek. Kde je sandbox zapnutý, je hranicí kolem nich.
Souborové nástroje harnessu v procesu (read, write, edit, apply patch, search, find, search_files) běží uvnitř procesu serveru, takže je neomezuje žádný profil sandboxu. Sandboxovaným runnerem příkazů projde jen nástroj bash. Ty nástroje omezuje jejich vlastní omezení cest a k tomu guardraily akcí.
Na hostiteli bez backendu první řádek neplatí vůbec. ACP a nástroj bash harnessu spadnou na očištění prostředí a politiku příkazů; Claude Code dědí prostředí hostitele přes NoSandboxAdapter. Server to řekne ve startovacím logu. Svůj si zkontroluj níže.

Rozhodni, co agent smí pushnout

Pro git push, GitHub, ticketing ani síť neexistuje přepínač u agenta. Každé z nich je pravidlo akce:

Pravidlo	Vestavěný výchozí	Co pokrývá
Odeslat na remote	Nejdřív se zeptat	Každý `git push` na GitHub, bez ohledu na adaptér
Otevřít pull request	Nejdřív se zeptat	`gh pr create` a nástroje pro pull requesty
Zveřejnit kontrolu nebo sloučení	Nejdřív se zeptat	`gh pr merge`, `gh pr review`, `gh pr comment`, `gh pr close`
Zápis do externího trackeru	Nejdřív se zeptat	Zápisy ticketů přes nástroje Control Center a `gh issue`
Přístup k síti	Povolit	Jestli má sandbox vůbec síť, a webové nástroje harnessu

Jdi do Nastavení → Pracovní prostor → Oprávnění agentů
Vyber rozsah — Pracovní prostor, Agent nebo Prostor — a na řádku pravidla vyber Povolit, Nejdřív se zeptat nebo Zakázat

Platí i pravidla pro push omezená na větve, třeba takové, které zakazuje push na main: viz Guardraily.

Kontrolní bod: požádej agenta, aby pushnul větev. U Nejdřív se zeptat dostaneš žádost o schválení s repozitářem a refy; u Zakázat git vypíše ! [remote rejected] <ref> (Control Center policy: …).

Jak se jednotlivá pravidla dostanou k běhu:

Push se vynucuje tím, co běh drží. Jeho token GitHub je instalační token GitHub App jen pro čtení, který umí číst obsah a pracovat s pull requesty. Jeho konfigurace gitu posílá každý push na GitHub na loopback bránu na cc_server, která se zeptá pravidla a teprve pak push předá se zapisovacím tokenem, který agent nikdy neuvidí. Brána předává jen do vlastního repozitáře worktree nebo do repozitáře na GitHubu propojeného s pracovním prostorem. Platí to pro každý adaptér.
Pull requesty a issues ze shellu se poznají podle příkazového řádku, v nástroji bash harnessu a přes hook v nástroji Bash v Claude Code. Agent, který příkaz schová (skript, eval, přímé volání API), touhle kontrolou projde, ale bránou pro push ne.
Klíče ticketingu se do sandboxu nikdy nevkládají. Agenti zapisují tickety přes nástroje MCP v Control Center, které se ptají pravidla.
Síť se vyhodnotí jednou, při startu běhu. Zakázat síť sandboxu vypne; Povolit a Nejdřív se zeptat ji nechají zapnutou a u Nejdřív se zeptat se nástroje harnessu web_fetch a web_search pořád ptají při každém volání. Dokud je síť zapnutá, je GitHub vždycky na seznamu povoleného odchozího provozu.

Zkontroluj, jestli jsou běhy agenta v sandboxu

Rozhodují o tom dvě věci, obě na serveru: jestli hostitel nabízí backend a jestli je --sandbox zapnutý. Zkontroluj je v tomhle pořadí.

Jdi do Nastavení → Server → Diagnostika a soukromí
Přečti kartu Sandboxing. Údaj Hostitel je stroj, na kterém běží cc_server, ne stroj, na který se díváš. Pole Backend uvádí Nativní sandbox (Seatbelt na macOS, bubblewrap na Linuxu a na WSL2) nebo Bez izolace. Údaj V platnosti je preference tohohle zařízení, ne obal, který server skutečně používá.
Přečti startovací log serveru. Vypíše přesně jeden ze tří řádků:
- agent sandbox ON plus poznámka k backendu — běhy jsou obalené
- no OS-native agent sandbox on this host plus nápověda k instalaci, kde nějaká je — běhy obalené nejsou
- agent sandbox DISABLED by --sandbox off — záměrné vypnutí

GET /healthz stav sandboxu nehlásí, takže kontrolou je startovací log.

Sandbox vypneš schválně — existuje proto, že na některém hostiteli se profil chová špatně — tak, že server spustíš s --sandbox off, nebo nastavíš CC_SERVER_SANDBOX=off. Výchozí hodnota je on a on znamená „použij backend, když ho hostitel má“, nikdy „vyžaduj ho“.

Nativní obal sandboxu ve dvou situacích nevznikne vůbec. Na Windows nativní sonda vždycky hlásí, že není k dispozici, a není co instalovat — odeslání agenta používá none. Backend microvm je zvlášť (interaktivní terminály a stanice) a pouští ho vlastní sonda podle jeho runtime. Na Linuxu a WSL2 musí být na PATH jak bwrap, tak socat; bez nich sonda hlásí, že není k dispozici, a pojmenuje chybějící balíčky.

Na Linuxu a WSL2 s nainstalovaným bubblewrapem se globy tajných souborů standardní politiky nedají vynutit u souborů, které agent vytvoří až později. Takový nativní běh teď selže, místo aby pravidla potichu ignoroval. Kladná sonda při startu proto nezaručí, že se odeslání na Linuxu umí rozběhnout. --sandbox off je záměrné vypnutí bez omezení, ne náhradní bezpečnostní hranice.

Zjisti, co režim už zakazuje

Režim se ukládá na prostor a do vyhodnocovače guardrailů vstupuje jako vrstva Předvolba režimu. Tři ze čtyř režimů jsou jen pro čtení a režim jen pro čtení odmítne jedenáct tříd efektů rovnou:

Režim	Worktree	Co předvolba odmítá
Agent (`chat`)	Zapisovatelný	Nic — platí vestavěné výchozí hodnoty
Plán	Jen pro čtení	Smazat soubor, zápis mimo worktree, vytvořit commit, odeslat na remote, otevřít pull request, zveřejnit kontrolu nebo sloučení, zápis do externího trackeru, nainstalovat balíček, spustit proces, změnit strukturu pracovního prostoru, ovládat izolované prostředí (stanici)
Kontrola	Jen pro čtení	Stejných jedenáct. Nejde vybrat — composer nabízí jen Agent, Plán a Orchestraci
Orchestrace	Jen pro čtení	Stejných jedenáct

Přístup k síti a čtení tajemství režim jen pro čtení schválně neodmítá: výzkum je jeho smysl.

Vyžaduj schválení, než akce proběhne

Schválení je rozhodnutí guardrailu, ne nastavení sandboxu.

Jdi do Nastavení → Pracovní prostor → Oprávnění agentů
Nastav třídu akce na Nejdřív se zeptat v rozsahu pracovního prostoru, agenta nebo prostoru

Rozhodnutí Nejdřív se zeptat běh přeruší a zeptá se tě. Když není připojený schvalovatel, selže uzavřeně a akce se odmítne. Celé pořadí vyhodnocení je v Nastavte guardraily.

Řešení problémů

Agent nemůže pushnout a já jsem to nezakázal

Přečti si, co git vypsal. Control Center policy: … znamená, že push zamítlo pravidlo nebo že Nejdřív se zeptat zůstalo bez odpovědi. … is not linked to this workspace znamená, že push míří do repozitáře, který není repozitářem worktree ani není propojený s pracovním prostorem. Control Center has no GitHub credential that can push … znamená, že GitHub App na tom repozitáři není nainstalovaná a žádný záložní údaj pushnout nemohl: nainstaluj aplikaci na ten repozitář nebo připoj GitHub.

Karta Sandboxing nehlásí nativní sandbox

Pak běhy agenta na tom hostiteli neobaluje Seatbelt ani bubblewrap a zbývající hranice jsou to, co máš. Na Linuxu a na WSL2 nainstaluj oba chybějící nástroje — sudo apt-get install bubblewrap socat — a restartuj server; startovací log by pak měl říct, že je sandbox zapnutý. Na Windows není nativní backend k instalaci, takže místo toho utáhni guardraily: viz Nastavte guardraily.

Agent se dostal k souboru mimo svůj worktree

Jestli je to očekávané, rozhoduje, který nástroj se k němu dostal.

Souborové nástroje harnessu v procesu (read, write, edit, apply patch, search, find, search_files) běží v procesu serveru, takže se na ně žádný profil sandboxu nevztahuje — jejich mez je vlastní omezení cest a k tomu guardraily. Příkaz bash nebo CLI Claude Code se obaluje tam, kde backend existuje, a tvoje registrované checkouty jsou uvnitř toho obalu v každém režimu se zákazem zápisu, včetně zápisů po rozřešení symlinku (na macOS se cesta dosažená přes /tmp nebo /var/folders rozřeší pod /private a oba zápisy se teď odmítají). Na hostiteli bez backendu nic z toho neplatí. V obou případech umí guardraily rovnou odmítnout Zápis mimo worktree.