Every safety control agentglass has today is global: the approve/deny gate, fail-open vs fail-closed (AGENTGLASS_GATE_FAILCLOSED), the write-disables. But risk isn't global — the same person wants "everything needs my approval" on the production repo, "anything goes" in the sandbox, and "no pushes, ever" on a client's codebase. Today the only way to express that is restarting the server with different env vars. Per-project governance + per-project hooks is how the serious setups run.

Proposal

A policy per project root, resolved by longest path match against a session's cwd:

// ~/.config/agentglass/config.json
{
  "policies": {
    "~/code/prod-api":   { "gate": ["Bash", "Write"], "failClosed": true, "gitWrite": false },
    "~/code/sandbox":    { "gate": [] },
    "~/clients/acme":    { "gitPush": false, "chatBypass": false }
  }
}

• The gate (server/src/gate.ts + hooks/gate_event.py) consults the policy for the calling session's project instead of one global switch — per-project tool matchers, per-project fail-open/closed
• The write-gates (git push, docker, chat bypass) become overridable per root, with the env vars keeping the global default
• Hook profiles: hooks/install_hooks.py --project already writes per-repo hooks; a policy could declare which profile a project gets (full gating vs telemetry-only), so bun run setup wires each project according to its declared risk
• UI: show the active policy on the session card / gate prompt ("gated by prod-api policy"), so an approval request explains why it's asking

Why it matters

The gate is agentglass's most differentiated feature, and one-size-fits-all is what keeps it turned off. Policies that match how people actually rank their repos ("prod is sacred, sandbox is free") make the control plane something you'd leave on.