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 is a stateless per-request proxy in front of one upstream MCP server. It runs the same policy engine over the tools/call requests an agent routes through it, so a tool that server exposes is subject to the same allow/block and sensitive-path overlay as a native call. But its distinct value is the part no pre-exec hook can do: it scans the server's responses for prompt-injection (PromptGuard 2, when the opt-in LlamaFirewall layer is enabled). A hook only ever sees the agent's outgoing call, never what a malicious or compromised MCP server sends back.

The gateway is not a package-install chokepoint. Catalog corroboration and install posture key off package-manager commands an agent runs through its native tools, which never reach the gateway. The gateway's job is defending the agent from the MCP servers it talks to. It is the enforcement path for Tier-3 harnesses and a stronger option for Hermes, but it only sees traffic you route through it: native tools and un-proxied MCP servers flow around it.

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. The gateway binds 127.0.0.1 by default and refuses any non-loopback bind unless you pass the explicit --allow-remote flag (it fails closed otherwise). The opt-in is the CLI flag only; there is no allow_remote_gateway config-file gate, so a poisoned project config cannot expose the gateway. The residual risk is that a deliberate --allow-remote bind is still plain HTTP: the per-session bearer token travels in cleartext. Keep the gateway on loopback, or put a TLS-terminating reverse proxy in front. See Security.