Skip to main content

​
OpenClaw Integration

This page documents how ClawControl integrates with OpenClaw in the current implementation.

​
Supported Binary and Version Expectation

  • Supported binary: openclaw
  • Minimum version expectation in code/docs: 0.1.0
  • CLI resolution supports explicit OPENCLAW_BIN override and common install paths

​
Dependency Layers (Important)

ClawControl separates dependency health into two layers:
  1. Gateway reachability (HTTP/WS probe).
  2. OpenClaw CLI availability (binary + command execution).
These are intentionally independent. A reachable gateway does not guarantee CLI-backed features are available. CLI-backed surfaces in this release include:
  • maintenance actions and recovery
  • models
  • plugins
  • cron
  • capability probing

​
Discovery and Resolution Behavior

Config resolution combines (in priority order):
  1. ClawControl settings (settings.json)
  2. environment variables
  3. OpenClaw config discovery (~/.openclaw, ~/.OpenClaw, ~/.moltbot, ~/.clawdbot)
  4. default loopback gateway URLs

​
Capability Probing

Capabilities endpoint probes OpenClaw and returns feature support map. Results are cached briefly and can be refreshed.

​
Command Safety Model

  • OpenClaw execution is allowlist-based.
  • Commands run via spawn with array args (no shell interpolation).
  • Dynamic command forms enforce required params.
  • Command execution results are logged in receipts.

​
Unavailable / Degraded Behavior

When OpenClaw is unavailable:
  • API responses return unavailable/degraded states or errors per endpoint contract.
  • UI renders empty or unavailable states using real data contracts.
  • No fake/demo fallback data is generated.
CLI-dependent API failures include additive metadata:
  • code: CLI_UNAVAILABLE, CLI_JSON_PARSE_FAILED, OPENCLAW_COMMAND_FAILED
  • fixHint: actionable remediation text when available

​
Last updated

2026-02-11