Integration

Beekeeper supports 17 agent harnesses across three tiers. The tier reflects how completely Beekeeper can intercept that harness's tool calls. Install a hook with beekeeper hooks install --target <harness> (the flag is --target, not --hook).

Verification ceiling. Only Claude Code is live-verified: confirmed end-to-end on a running harness (hook fires → tool blocked → audit written). The other 16 harnesses are implemented against published vendor contracts and validated by contract-shape tests that assert the correct exit code and JSON, but do not run a real harness. Whether a given harness honors the contract in a live session is not verified in CI.

Tier 1

Claude Code (live-verified)

beekeeper hooks install --target claude-code

Installs PreToolUse/PostToolUse hooks into ~/.claude/settings.json, merging with existing hooks. Hooks reload mid-session. This is the one harness verified end-to-end on a live agent.

Other Tier-1 harnesses (documented)

Install each with its target name:

beekeeper hooks install --target codex   # requires [features] hooks=true in config.toml

beekeeper hooks install --target cursor   # see caveat below

beekeeper hooks install --target augment

beekeeper hooks install --target codebuddy

beekeeper hooks install --target qwen

beekeeper hooks install --target gemini   # Gemini CLI (native decision field)

beekeeper hooks install --target copilot   # flat permissionDecision JSON

• Cursor is fail-OPEN by default: its hook config must set failClosed:true (Beekeeper writes this), and it uses three separate events (beforeShellExecution / beforeMCPExecution / beforeReadFile), not a single preToolUse.
• Windsurf only honors exit code 2: it has no JSON deny form and is fail-OPEN on any other exit code. On Windows it uses the powershell hook key.
• Antigravity field names are medium-confidence in upstream docs, so Beekeeper emits both the decision and permissionDecision forms defensively.

Use --dry-run to preview any install without writing, and beekeeper hooks uninstall --target <harness> to remove only Beekeeper's entry.

Tier 2 (caveats)

Hermes: fail-OPEN

beekeeper hooks install --target hermes

Hermes ignores hook exit codes entirely. A block is carried only by emitting {"action":"block","message":"..."} (non-empty message) as the first JSON object on stdout. Any hook timeout, crash, or non-JSON stdout causes Hermes to allow the tool call; there is no exit-code backstop. Prefer the MCP gateway for Hermes use cases where reliable block enforcement matters.

Cline: macOS / Linux only

beekeeper hooks install --target cline

Cline's hook is an executable file (.clinerules/hooks/PreToolUse). Windows cannot run Unix executable scripts this way, so the Cline installer is macOS/Linux only and returns an explicit error on Windows.

OpenCode: plugin gaps

beekeeper hooks install --target opencode

OpenCode uses a JS plugin (tool.execute.before); Beekeeper ships a plugin that throws to block. The plugin does not intercept subagent task calls (issue #5894) or, historically, MCP calls (#2319).

Tier 3: MCP gateway only (native tools UNGUARDED)

beekeeper hooks install --target kilo

beekeeper hooks install --target trae

beekeeper hooks install --target continue

beekeeper hooks install --target openclaw

These four harnesses are integrated through the MCP gateway, not a pre-exec hook file. Beekeeper intercepts only the MCP tool calls they route through the gateway; any native or built-in tools the harness runs directly (Bash, file read/write, shell) are UNGUARDED. For Kilo and Trae this is a documented upstream limitation (no pre-exec hook; e.g. Kilo FR #5827). Continue and OpenClaw are wired via their MCP client config (~/.continue/config.yaml, ~/.openclaw/config.json). For full pre-exec coverage, use a Tier-1 harness.

These targets print the gateway configuration instructions (point your MCP client at http://127.0.0.1:7837/mcp with the session token) instead of writing a hook.

MCP gateway

The gateway intercepts MCP JSON-RPC tool calls at the network layer: the enforcement path for Tier-3 harnesses and a more robust option for Hermes.

beekeeper gateway --upstream <upstream-mcp-url> --port 7837

beekeeper gateway token   # print the session bearer token

beekeeper gateway status   # running status, bound address, masked token

It binds 127.0.0.1 by default and authenticates with a per-session bearer token. Point your harness's MCP client at http://127.0.0.1:7837/mcp with that token.

Remote-bind caveat. --bind 0.0.0.0 exposes the gateway (and the upstream MCP server behind it) over plain HTTP: the bearer token travels in cleartext. The CLI help text references an allow_remote_gateway config gate, but that gate is not implemented in this release; the flag flows straight to net.Listen. Do not bind the gateway to a non-loopback interface without a TLS-terminating reverse proxy in front. See Security.