Agents

Claude Code Tested

Tested: one command builds the plugin and installs it.

Build for Claude Code

Builder value: --client claude-code

With --apply, chock runs these steps for Claude Code:

1. claude plugin marketplace add ~/.chock/marketplace/claude-code

2. claude plugin install chock-guardrails@chock-local

Both commands are safe to repeat. The plugin loads in place from the directory: restart the Claude Code session, or run /reload-plugins in it, to pick up a rebuild.

Cannot install chock? Use the per-policy marketplace, which needs Python 3.11+, git and a bash but no chock: chock-claude-plugins. Install a policy from one place only, never both: each copy runs its own hook.

Cursor Tested

Tested: one command builds the plugin and installs it. On Cursor Teams and Enterprise an admin setting (Allow Local Plugin Imports) can turn local plugins off, and an installed marketplace plugin of the same name takes precedence over this one.

Build for Cursor

Builder value: --client cursor

With --apply, chock runs these steps for Cursor:

Cursor loads ~/.cursor/plugins/local/chock-guardrails as a local plugin: run "Developer: Reload Window" (or restart Cursor), then check it under Customize. There is no command to run.

Cannot install chock? Use the per-policy marketplace, which needs Python 3.11+, git and a bash but no chock: chock-cursor-plugins. Install a policy from one place only, never both: each copy runs its own hook.

Codex Tested

Tested: one command builds the plugin and installs it. Codex skips a plugin's hooks until you review and trust them in /hooks, and asks again after a hook changes: until then every policy here is advisory.

Build for Codex

Builder value: --client codex

With --apply, chock runs these steps for Codex:

1. codex plugin marketplace add ~/.chock/marketplace/codex

Then install chock-guardrails from the chock-local marketplace in /plugins, and review and trust its hooks in /hooks: until you do, they do not run.

Cannot install chock? Use the per-policy marketplace, which needs Python 3.11+, git and a bash but no chock: chock-codex-plugins. Install a policy from one place only, never both: each copy runs its own hook.

GitHub Copilot Tested

Tested: one command builds the plugin and installs it. In Copilot CLI, a gate checks the write before it lands (seen in a live run on 2026-10-11, CLI 1.0.94 on Windows). In VS Code agent mode that is unmeasured.

Build for GitHub Copilot

Builder value: --client copilot

With --apply, chock runs these steps for GitHub Copilot:

1. copilot plugin marketplace add ~/.chock/marketplace/copilot

2. copilot plugin install chock-guardrails@chock-local

VS Code finds plugins the Copilot CLI installed. Without the CLI, add the plugin folder to your VS Code user settings yourself:

{
  "chat.pluginLocations": {
    "~/.chock/marketplace/copilot/claude/chock-guardrails": true
  }
}

Cannot install chock? Use the per-policy marketplace, which needs Python 3.11+, git and a bash but no chock: chock-copilot-plugins. Install a policy from one place only, never both: each copy runs its own hook.

Devin Tested

Tested: one command builds the plugin and installs it. Devin runs plugin hooks on a best-effort basis. A hook that errors or times out lets the action through. This client names no file-write tool a hook can match. So a gate checks what a turn wrote only at turn end, and it does not stop the write when it happens.

Build for Devin

Builder value: --client devin

With --apply, chock runs these steps for Devin:

On Windows, devin plugins install --local creates a symbolic link, so it needs Developer Mode (Settings > System > For developers) or an elevated shell; otherwise it fails with "os error 1314: A required privilege is not held by the client".

1. devin plugins install --local ~/.chock/marketplace/devin/chock-guardrails

The plugin is linked in place: a rebuild applies from the next Devin session.

Cannot install chock? Use the per-policy marketplace, which needs Python 3.11+, git and a bash but no chock: chock-devin-plugins. Install a policy from one place only, never both: each copy runs its own hook.

Grok Tested

Tested: one command builds the plugin and installs it. If a Grok hook times out, crashes or returns malformed output, the action goes through. Only an explicit deny blocks, and an allowManagedHooksOnly policy skips plugin hooks. No gate runs here, because agentseam records neither a write-tool vocabulary nor a blocking Stop for grok.

Build for Grok

Builder value: --client grok

With --apply, chock runs these steps for Grok:

1. grok plugin install ~/.chock/marketplace/grok/chock-guardrails --trust

Plugins are off in grok until enabled, and chock does not edit grok's config: run grok plugin list for the name grok gave this plugin (chock expects chock-guardrails, its folder name; the docs do not say how a plugin with no plugin.json is named), then grok plugin enable <name>, or add it to enabled under [plugins] in ~/.grok/config.toml, or press Space on it in the Plugins tab. Re-run the install command after a rebuild.

goose Tested

Tested: one command builds the plugin and installs it. goose denies a PreToolUse call when its hook fails, because every entry sets on_failure: block. Its Stop hooks keep the default, so if a gate fails at turn end, the turn still finishes. On Windows, goose runs every hook with sh -c, so Git for Windows' sh must be on PATH. Without it, every tool call is denied, even a harmless one, because the hook cannot start (on_failure: block).

Build for goose

Builder value: --client goose

With --apply, chock runs these steps for goose:

goose discovers ~/.agents/plugins/chock-guardrails as a user plugin, in every project: start a new goose session. There is no command to run (goose plugin install takes a git URL only). To turn it off, add chock-guardrails to disabledPlugins in ~/.config/goose/settings.json.

Antigravity Tested

Tested: one command builds the plugin and installs it. Antigravity documents no fail mode for a hook and no plugin-root variable. The hooks name the plugin folder by absolute path, and a gate checks what a turn wrote only at turn end.

Build for Antigravity

Builder value: --client antigravity

With --apply, chock runs these steps for Antigravity:

1. agy plugin install ~/.chock/marketplace/antigravity/chock-guardrails

Antigravity 2.0 and the IDE read plugin folders from ~/.gemini/config/plugins/ instead: copy ~/.chock/marketplace/antigravity/chock-guardrails there. Its hooks name ~/.chock/marketplace/antigravity/chock-guardrails by absolute path (Antigravity documents no plugin-root variable), so keep that folder where it is; re-run the install command after a rebuild.

OpenHands Untested

Untested: the command builds the plugin, and you apply the steps in OpenHands yourself. OpenHands documents no plugin-root variable: the hooks name the plugin folder by absolute path, and its hook runner blocks only on exit code 2 or a deny, so any other hook failure lets the call through.

Build for OpenHands

Builder value: --client openhands

Then, in OpenHands:

OpenHands loads a local plugin when it starts: run openhands --plugin ~/.chock/marketplace/openhands/chock-guardrails, or add "~/.chock/marketplace/openhands/chock-guardrails" to sources under [plugins] in ~/.openhands/config.toml (chock does not edit it). Its hooks name ~/.chock/marketplace/openhands/chock-guardrails by absolute path (OpenHands documents no plugin-root variable), so keep that folder where it is; a rebuild applies from the next start.

Kimi Code Untested

Untested: the command builds the plugin, and you apply the steps in Kimi Code yourself. Kimi Code lets a call through when a hook errors, times out or exits with any code other than 2. It cannot prompt, so an ask is not enforced there. It applies a plugin to every project you open. It installs from its TUI only and runs a copy, so reinstall after a rebuild. On Windows, the shell Kimi Code runs hook commands with is unmeasured, and the hooks read ${KIMI_PLUGIN_ROOT}. This path is not tested there.

Build for Kimi Code

Builder value: --client kimi-code

Then, in Kimi Code:

Kimi Code installs plugins from its TUI only, and chock does not drive it: in Kimi Code run /plugins install ~/.chock/marketplace/kimi-code/chock-guardrails, then /reload (or /new). Kimi copies the plugin to $KIMI_CODE_HOME/plugins/managed/chock-guardrails/ and runs that copy, so after a rebuild install it again. The plugin applies to every project you open (Kimi has no project-level plugin scope); /plugins disable chock-guardrails turns it off.

Factory Droid Untested

Untested: the command builds the plugin, and you apply the steps in Factory Droid yourself. Factory Droid treats a hook exit other than 0 or 2 as a non-blocking error and lets the call through, ignores this plugin's hooks under an org's allowManagedHooksOnly, and (agentseam's vendor data) degrades an ask to a block.

Build for Factory Droid

Builder value: --client factory-droid

Then, in Factory Droid:

Run these from the root of the project the plugin is for: --scope project records it in that project's Droid settings. The marketplace is local to this machine; chock publishes nothing.

1. droid plugin marketplace add ~/.chock/marketplace/factory-droid/chock-local

2. droid plugin install chock-guardrails@chock-local --scope project

Droid names a local marketplace from its source; if droid plugin marketplace list shows a name other than chock-local (a --dest folder named otherwise), install chock-guardrails@<that name>. Droid copies the plugin into its cache: after a rebuild run droid plugin marketplace update and droid plugin update chock-guardrails@chock-local --scope project, then start a new session.