---
title: OpenClaw integration
description: How DefenseClaw integrates with OpenClaw end-to-end — fetch interceptor, before_tool_call hook, correlation headers, plugin-mediated HITL approvals, and the audit loop.
keywords:
  - DefenseClaw OpenClaw integration
  - OpenClaw plugin
  - OpenClaw before_tool_call
  - OpenClaw fetch interceptor
  - OpenClaw HITL
---

OpenClaw is the connector DefenseClaw was designed against. It is also the only connector that ships a first-party plugin in the same repository (`extensions/defenseclaw/`). That plugin owns the OpenClaw-side wiring; the gateway and CLI own everything else.

<Video
  src="openclaw"
  caption="Plugin install + first guardrail. The DefenseClaw plugin loads inside OpenClaw, the gateway picks up the correlation header, and policy decisions stream back through the chat UI."
/>

## Components

<Cards>
  <Card title="DefenseClaw plugin" description="TypeScript plugin under extensions/defenseclaw/. Hooks into OpenClaw's fetch interceptor and before_tool_call lifecycle." />
  <Card title="defenseclaw-gateway" description="Go sidecar. Receives plugin requests, evaluates policy, returns verdicts, and writes the audit row." />
  <Card title="DefenseClaw CLI" description="Python operator surface. Runs setup, exposes the TUI, drives HITL approvals." />
</Cards>

## End-to-end flow

<Sequence
  caption="Three interception points let DefenseClaw inspect every interesting moment in OpenClaw's lifecycle and surface HITL approvals back through the chat origin."
  participants={[
    { id: 'u',  label: 'User',                kind: 'operator' },
    { id: 'oc', label: 'OpenClaw',            kind: 'agent' },
    { id: 'p',  label: 'DefenseClaw plugin',  kind: 'connector' },
    { id: 'g',  label: 'defenseclaw-gateway', kind: 'gateway' },
    { id: 'op', label: 'Operator (TUI)',      kind: 'operator' },
  ]}
>
  <Message from="u"  to="oc" label="prompt" />
  <Message from="oc" to="p"  label="fetch (LLM request)" />
  <Message from="p"  to="g"  label="POST /v1/inspect (X-DefenseClaw-Correlation-Id)" />
  <Message from="g"  to="p"  kind="return" label="allow / block / pause" />
  <Message from="g"  to="op" label="enqueue approval (when paused)" />
  <Message from="op" to="g"  kind="return" label="approve / deny" />
  <Message from="g"  to="p"  kind="return" label="resolved verdict" />
  <Message from="p"  to="oc" kind="return" label="forward (or reject)" />
  <Message from="oc" to="p"  label="before_tool_call(name, args)" />
  <Message from="p"  to="g"  label="POST /v1/tool/inspect" />
  <Message from="g"  to="p"  kind="return" label="verdict" />
  <Message from="p"  to="oc" kind="return" label="allow / block" />
  <Message from="oc" to="u"  label="response" />
</Sequence>

## Correlation headers

Every plugin → gateway request carries `X-DefenseClaw-Correlation-Id` so the audit log can stitch a tool call back to the prompt that triggered it. The plugin generates one ID per OpenClaw turn; the gateway re-uses it for every downstream verdict.

## HITL: the only connector with plugin-mediated approval

OpenClaw is one of two connectors (alongside Claude Code) where HITL approvals reach the operator inside the agent UI. The DefenseClaw plugin queues approvals in OpenClaw's chat origin, so the operator approves or denies without leaving OpenClaw.

The other connectors fall back to a downgraded confirm verdict surfaced through `defenseclaw tui`. See the [HITL page](/docs/hitl) for the per-connector matrix.

## Files DefenseClaw owns inside the OpenClaw tree

<Files>
  <Folder name="~/.openclaw" defaultOpen>
    <File name="openclaw.json (allow + load entries for the DefenseClaw plugin)" />
    <Folder name="extensions">
      <Folder name="defenseclaw">
        <File name="openclaw.plugin.json" />
        <File name="package.json" />
        <Folder name="dist">
          <File name="index.js" />
        </Folder>
      </Folder>
    </Folder>
  </Folder>
</Files>

DefenseClaw never touches anything outside `extensions/defenseclaw/` and the `allow` / `load` arrays in `openclaw.json`. Backups are byte-for-byte; teardown either restores the file or surgically removes only DefenseClaw entries when the file has drifted.

## When this is the right connector

Pick OpenClaw when:

- You want the strongest enforcement contract: proxy-mode interception, sandbox subprocess policy, native ask + plugin-mediated approval.
- You're already running OpenClaw or are open to switching from Codex / Claude Code for security-critical workflows.
- You need fail-closed behaviour on transport failures.

If you're not running OpenClaw, the [Claude Code](/docs/connectors/claudecode) connector is the closest hook-only equivalent and supports native ask on PreToolUse.
