Chock policies for Copilot CLI and VS Code agent mode — a real PreToolUse deny hook where the client supports it.
An agent you're running can already touch your shell, your git history, and your CI config.
You want it to move fast without being the reason a stray rm -rf actually happens. Telling
it to be careful in a prompt is not a guarantee; a plugin that can refuse the command is
closer to one — and it should be honest about which of those two it is.
# VS Code / GitHub Copilot: add this repository as a plugin marketplace, then install a
# plugin by name. See the Copilot plugins marketplace and VS Code's agent-plugins docs:
# https://github.com/github/copilot-plugins
# https://code.visualstudio.com/docs/agent-customization/agent-plugins
These packages use the Claude plugin format, which VS Code and GitHub Copilot CLI read
natively (VS Code auto-detects the format and sets CLAUDE_PLUGIN_ROOT for the hook).
Two kinds of package enforce here, and they enforce differently.
Guard policies ship a PreToolUse hook that judges a shell command before it runs. The
adapter always exits 0 and carries its verdict as JSON on stdout (permissionDecision: "deny"),
so the refusal is the client reading that answer, not an exit status.
Gate policies judge what a turn writes rather than what it runs. In the copilot/ tree
they are wired at Stop, re-reading what the turn left on disk; the claude/ tree adds
PreToolUse on the write tools, judging the file a write would create.
Both need python3 on PATH: without it a fail-open client allows silently. A guard that
crashes is handled per that client's description; a gate that cannot reach a decision refuses
rather than allowing something it never judged. Advisory policies are a skill the client reads;
they shape behaviour but cannot block anything on their own. See PLUGINS.md for the full list: each
policy, its version, whether it enforces or advises in this client, and a catalog link.
Every file here is compiled from policy sources in chock-catalog by chock. Pull requests against this repository are closed automatically — open them against the catalog instead.
- Generated only: CI regenerates from the pinned catalog and fails on any difference.
- Byte-identical guards: each guard script is a verbatim copy of its policy's source in the catalog, and the hook adapter a verbatim copy of its framework source.
- Best-effort, not a boundary: guards are pattern-based filters; see SECURITY.md.
- Tested upstream, and gated: every policy ships an eval suite
(
base/<policy>/evals/suite.yaml) in the catalog, and the publish workflow runschock checkandchock check --only evalsbefore packaging anything — a policy whose evals fail cannot reach this repository. The tests live in the catalog because the policy source does; this repository is compiled output. - This README is hand-written, as are
SECURITY.mdand the workflows under.github/, so they sit outside the generated-only guarantee.
Nothing above asks for trust that cannot be checked. This rebuilds the published tree from source and compares it with what is committed here:
git clone https://github.com/open-coder-ai/chock-copilot-plugins dist
git clone https://github.com/open-coder-ai/chock-catalog catalog
git clone --branch "$(tr -d '[:space:]' < catalog/.framework-ref)" \
https://github.com/open-coder-ai/chock framework
pip install ./framework
chock plugin build --repo catalog --policies-dir base --format agent-plugins --out-dir dist
chock plugin build --repo catalog --policies-dir base --format claude --out-dir dist
chock plugin build --repo catalog --policies-dir base --format copilot --out-dir dist
chock marketplace build --dist dist
git -C dist diff --exit-code && git -C dist status --porcelainSilence from both git commands means this repository is byte-identical to a fresh build
from the catalog. The framework ref comes from the catalog's own .framework-ref, which is
what the publish and Generated-only workflows read, so this recipe cannot drift from the
release a tree was actually built with.
chock-market.lock records a sha256 per published plugin directory, so one package can be
checked without rebuilding the rest.
If you are listing these plugins in a marketplace, pin both a tag and the full commit SHA. The tag names the release; the SHA is what holds the reviewed bytes still.
| You want to | Go to |
|---|---|
| Fix or add a policy | chock-catalog — it reaches every client from there, including this one |
| Report that a guard did or did not block on your Copilot CLI or VS Code version | an issue on chock, which records what each package claims. No package here carries a witnessed block yet — the claims are read from vendor documentation — so a first-hand "it blocked" or "it fails open where you say it fails closed" is the most useful result you can send |
| Report a bug in how packages are generated | chock, where the emitter lives |
| Fix this README | here — it is hand-written, not generated |
| agentseam | the primitives — one handler API and a verified capability matrix across 16 agents |
| chock | the compiler — one policy into git hooks, CI gates and native pre-tool hooks |
| chock-catalog | the policies — 42, each labelled enforced or advisory, with replayed evals |
| context-report | the evidence — a signed report of whether an agent artifact actually works |
| chock-threat-intel | the threat ledger the catalog's policies answer to |
| chock-{claude,cursor,copilot,codex}-plugins | the catalog, packaged for each agent's plugin format (generated) |
| chock-quickstart · chock-example | template repos: what chock init leaves behind, and a full adoption |
Apache-2.0, same as the framework and the catalog.
