Which protection do I need?
This page asks you one question: how much protection you want. Where capabilities land is not a decision — delivery is routed for you, and the first section below says what that routing is so the second one makes sense. New to a word below? Every term is defined in concepts.
Your CLIs are the agent tools you run — Claude Code, Codex, Cursor, and the rest.
First, already decided: how capabilities reach your CLIs#
You do not have to choose. Delivery is routed, not picked: AgentStack decides per capability, from what kind it is and which CLI it is going to, and says what it decided. agentstack more delivery shows the routing for your project.
| Capability | Where it goes | Why |
|---|---|---|
| Skills · MCP servers, on a CLI that speaks MCP | served live, on demand | brokered, policy-checked, digest-verified, recorded — and nothing generated lands in your repo for them |
| House rules · settings | written into native files | a setting only a file carries; house rules because no live channel a CLI is known to consume varies by model |
| Hooks · extensions | written into native files, reviewed in full every time | they run code |
| Anything, on a CLI that reads files only | written into native files | that CLI has no live channel |
Most projects use both lanes at once.
The delivery override: render locally. agentstack more delivery render-locally --write (add --harness <id> for a single CLI) writes files even where the live channel would have worked. It is the only setting that changes the routing; materializing one toolset's files right now, without changing the routing, is agentstack use <toolset> --write instead. Pick it for:
- offline work, or deterministic native files you can inspect with ordinary filesystem tools;
- a rule against a persistent background process;
- debugging, or testing a CLI's own behaviour, without another runtime dependency.
Switching it changes only where the bytes go — never what you trust or what your policy allows. It costs you no review. A preference declares no capability, so your existing grant still holds after the write.
Either lane still passes the trust gate. On an untrusted or drifted project neither the live channel nor the file lane delivers servers, skills, instructions, hooks or extensions — see concepts — trust.
The older per-project delivery modes (static, clean-at-rest, zero-files) are readings of a project's current shape, not choices: agentstack set-mode is retired and delivery is routed for you. See delivery in the reference for what each still means, and ARCHITECTURE — delivery is routed, not chosen for the routing itself and how delivery sits beside selection and isolation.
Then, your decision: how much protection?#
Find the row that sounds like you. The last column says how strongly each option is enforced, in the enforcement matrix's own words.
| You are… | You need | Command | What it actually does |
|---|---|---|---|
| just syncing config across your CLIs | config sync | init then apply --write | Copies your reviewed config into each CLI. No runtime check — nothing is blocked once an agent is running. |
worried about rm -rf or .env accidents | the guard | guard install --write | Cooperative: catches an agent's accidents through each CLI's own hook. Not a determined attacker. |
| cloning repos you didn't write | the trust gate | gateway connect then trust . | A repo's servers, skills, instructions, hooks and extensions stay inert until you trust it — not loaded, and not written to disk either. Trust gates whether they reach your tools; it does not sandbox the code. |
| launching a frozen, verified surface, no Docker | a Protected run — already the default | run <cli> | Fail-closed trust and pin checks before launch, then a frozen surface. This is what a plain agentstack run does now; --unprotected opts out. Labelled HOST / PROTECTED. Not kernel isolation — the agent still runs as you. |
| running sensitive work that must not leak | Lockdown (Docker) | run <cli> --sandbox --lockdown | Container with no route out; egress is enforced. Unapproved egress is blocked — that never means exfiltration is impossible. Labelled LOCKDOWN / ENFORCED. |
The rows stack: guard, the trust gate, and a protected or lockdown run each add protection the one above does not, so most people end up combining several. The legend words — cooperative, enforced, coarse, unsupported — are defined once in the enforcement matrix, which spells out exactly what each mode does and does not stop. --lockdown needs Docker; the protected default does not.
Not sure? Let delivery stay automatic and add guard install --write — that is the right answer for almost everyone. Get started covers the delivery half; lock down a run walks the protection ladder from the protected default upward.
Source of truth: docs/choose.md — this page is generated from it.