Connectors
Fifteen active connectors share one adapter interface while exposing connector-specific proxy, hook, ACP, policy, telemetry, and approval capabilities.
Connectors are the adapter layer between agent frameworks and DefenseClaw. They share one Go interface, but each connector advertises only the capabilities its agent actually exposes. Proxy routing, lifecycle hooks, custom policy callbacks, component discovery, CodeGuard, subprocess wrapping, native telemetry, and approval support therefore vary by connector.
Integration families
Proxy connectors
OpenClaw, ZeptoClaw. Model requests routed through the DefenseClaw proxy and their responses are inspected; OpenClaw classifies recognized provider/request shapes, while ZeptoClaw rewrites configured provider api_base values.
Hook connectors
Claude Code, Codex, Amp, Cursor, Devin, GitHub Copilot CLI, OpenHands, Antigravity, Hermes, OpenCode, and Kiro. DefenseClaw wires into the agent's native lifecycle hooks; the agent talks directly to its upstream. Kiro also has native ACP support.
Custom policy connector
OmniGent. DefenseClaw installs an in-process Python policy bridge and maps six awaited policy phases to ALLOW, ASK, or DENY without proxying model traffic.
ACP guard
The shared guard protects verified native ACP entry points for Kiro and other connectors without creating an IDE-specific extension.
Compatibility contracts
Versioned hook contracts, setup-time connector version checks, and the runtime hook_contract_lock.json.
One gateway, many hook connectors. A single DefenseClaw gateway can serve several hook connectors at once, each with its own guardrail posture under guardrail.connectors.<name> — pick Add (not Replace) when you run a second setup <connector>. Proxy connectors (OpenClaw, ZeptoClaw) bind a listener and own the traffic plane, so they can't be multi peers. See Multi-connector.
Pick yours
Platform support
Every connector page now keeps its macOS/Linux and native Windows setup in one place, including platform-specific paths, dependencies, and enforcement limits. Supported means the connector is available through the ordinary setup path; it does not invent official-client validation evidence when that evidence has not been recorded.
| Connector | macOS / Linux | Native Windows x64 | Important Windows boundary |
|---|---|---|---|
| Claude Code | Supported | Supported | Direct executable hooks; Git for Windows is optional and WSL is outside the native contract. |
| Codex | Supported | Supported | Event-bound system PowerShell bridge to the packaged hook executable plus native OTLP; no resumable native ask response. |
| Kiro | Supported | Supported | Regular connector: workspace-scoped native hooks in .kiro/hooks for Kiro IDE and kiro-cli --v3, a CLI 2.x agent config for bare kiro-cli, plus optional ACP via the shipped stdio guard. |
| Amp | Supported | Supported | Owner-only TypeScript system-policy plugin; no shell hook or native OTLP exporter. |
| Cursor | Supported | Supported | Managed PowerShell adapter; DefenseClaw does not enable Cursor's native ask response. |
| Devin CLI and Devin Desktop | Supported | Supported | Exact same-user CLI 3000.4.25 hook admission. Devin Desktop's default Devin Local agent shares the CLI hooks; its legacy Cascade agent is not covered. The separate native devin acp entry point is cataloged for the shared guard, while cloud Devin, proxy, and native OTLP remain excluded. |
| GitHub Copilot CLI | Supported | Supported | Uses Copilot's PowerShell hook field; upstream Windows sandboxing cannot enforce per-path denials. |
| Antigravity | Supported | Supported | Native PowerShell launcher; only PreToolUse can block or ask. |
| Hermes | Supported | Supported | Direct executable hook is shell-free, but Hermes' own terminal tool depends on its bundled Git Bash. |
| OpenCode | Supported | Supported | Direct Windows execution is supported; only awaited tool.execute.before can block. |
| OmniGent | Supported | Supported — native degraded | Server/SDK policy path only; terminal wrappers and filesystem/network/L7 sandbox parity are unavailable. |
| OpenHands | Supported | Unsupported | OpenHands CLI requires WSL, and DefenseClaw has no WSL connector path. |
| OpenClaw | Supported | Unsupported | Its DefenseClaw integration requires the guardrail proxy, which native Windows does not host. |
| ZeptoClaw | Supported | Unsupported | Its DefenseClaw integration requires the guardrail proxy and upstream publishes macOS/Linux builds. |
Connectors that earlier releases shipped under other names, or that were removed, are listed with migration steps in Upgrade → Renamed and removed connectors.
Capability summary
| Family | Connectors | Data path | Enforcement boundary |
|---|---|---|---|
| Proxy | OpenClaw, ZeptoClaw | DefenseClaw receives and forwards model traffic | Request/response policy in the proxy |
| Hook | Claude Code, Codex, Amp, Cursor, Devin, GitHub Copilot CLI, OpenHands, Antigravity, Hermes, OpenCode, Kiro | Agent remains connected directly to its upstream | Only the blocking events declared by that connector's selected hook contract; Cursor action uses event-native deny from its user hook. Kiro also exposes native ACP. |
| Custom policy | OmniGent | Agent remains connected directly to its upstream | Six in-process policy phases mapped to ALLOW, ASK, or DENY |
| ACP | Tested Kiro + Zed path; cataloged native modes for Cursor, Hermes, OpenCode, Copilot, and Devin. Native entry points only — no bridges | DefenseClaw mediates client ↔ agent JSON-RPC | Bidirectional prompt, output, approval, filesystem, terminal, and extension-method policy |
Native ask is event-specific: OpenClaw (before_tool_call), Claude Code
(PreToolUse), Copilot CLI (preToolUse), Antigravity (PreToolUse only),
Amp (tool.call and model-bound tool.result in the active foreground
thread), and OmniGent's three pre-action phases. DefenseClaw does not enable
Cursor's native ask response; Cursor confirm verdicts remain attributed
alerts. Other confirmation verdicts use the connector's documented fallback.
See the HITL reference for the canonical per-event matrix and
Connector Compatibility for exact version
ranges and script generations.
OpenShell sandbox
defenseclaw sandbox run <harness> runs a coding agent in an NVIDIA OpenShell
sandbox that sees only your project folder, on Linux, or on a Mac with Apple
silicon in a MicroVM of its own that works on a copy of the folder
(macOS); the sandbox guide
covers setup and every command.
DefenseClaw builds sandbox images for these harnesses:
- Run today: Claude Code, Codex, OpenCode, GitHub Copilot CLI, Kiro CLI, Hermes Agent, OpenHands, OmniGent and Antigravity.
- Cannot run yet: Amp, Cursor Agent and Devin CLI need a vendor account before any agent turn, so their images have not passed DefenseClaw's hook check.
Claude Code, Codex, Copilot CLI, Cursor Agent and OmniGent register their hooks in a root-owned managed policy or configuration, so user and project settings cannot switch them off. The others are in the user tier: the agent can edit their hook file, or code the agent or a repository adds runs beside the hooks. Every other connector is pending. The capability matrix shows each harness's image pin, tier and verification.
How a connector is structured
The interface is defined in internal/gateway/connector/connector.go; each per-connector file (claudecode.go, codex.go, cursor.go via hook_only.go, ...) implements it.
Troubleshooting
Fix a standalone DefenseClaw enterprise deployment by lifecycle error code, MDM wrapper code, hook refusal code, or symptom, on Windows, Linux, and macOS.
Connector Compatibility
Versioned hook contracts, setup-time compatibility checks, and the runtime hook contract lock for DefenseClaw connectors.