# Agents

From your picks, chock.sh builds one plugin for Claude Code, Cursor, Codex, GitHub Copilot, Devin, Grok, goose, Antigravity, OpenHands, Kimi Code and Factory Droid. Cannot install chock? Where an agent has a plugin repository, it is a per-policy marketplace that needs no chock on the machine. Pick an agent in the builder and the command builds one plugin for it. Tested means a person has seen chock refuse actions in that agent. For a tested agent, the command also installs the plugin. For an untested agent, the command builds the plugin and you follow the install steps yourself.

## Claude Code (`--client claude-code`, tested)

Tested: one command builds the plugin and installs it. Builder: /coding/builder/#client=claude-code.

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

1. (command)

   ```sh
   claude plugin marketplace add ~/.chock/marketplace/claude-code
   ```

2. (command)

   ```sh
   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: https://github.com/open-coder-ai/chock-claude-plugins Install a policy from one place only, never both: each copy runs its own hook.

## Cursor (`--client 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. Builder: /coding/builder/#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: https://github.com/open-coder-ai/chock-cursor-plugins Install a policy from one place only, never both: each copy runs its own hook.

## Codex (`--client 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. Builder: /coding/builder/#client=codex.

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

1. (command)

   ```sh
   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: https://github.com/open-coder-ai/chock-codex-plugins Install a policy from one place only, never both: each copy runs its own hook.

## GitHub Copilot (`--client 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. Builder: /coding/builder/#client=copilot.

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

1. (command)

   ```sh
   copilot plugin marketplace add ~/.chock/marketplace/copilot
   ```

2. (command)

   ```sh
   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: https://github.com/open-coder-ai/chock-copilot-plugins Install a policy from one place only, never both: each copy runs its own hook.

## Devin (`--client 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. Builder: /coding/builder/#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. (command)

   ```sh
   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: https://github.com/open-coder-ai/chock-devin-plugins Install a policy from one place only, never both: each copy runs its own hook.

## Grok (`--client 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. Builder: /coding/builder/#client=grok.

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

1. (command)

   ```sh
   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 (`--client 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`). Builder: /coding/builder/#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 (`--client 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. Builder: /coding/builder/#client=antigravity.

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

1. (command)

   ```sh
   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 (`--client 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. Builder: /coding/builder/#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 (`--client 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. Builder: /coding/builder/#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 (`--client 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. Builder: /coding/builder/#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. (command)

   ```sh
   droid plugin marketplace add ~/.chock/marketplace/factory-droid/chock-local
   ```

2. (command)

   ```sh
   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.