CheetahClaws in HarnessRouter
HarnessRouter v0.25.0 adds CheetahClaws 3.5.88 as backend sixteen, driven in process through the upstream agent loop.
Page reviewed 4 Oct 2026 Source and review policy
Set the permission boundary before the first task
Section titled “Set the permission boundary before the first task”CheetahClaws v3.5.88 is both the latest upstream release observed on 4 October and the CE v0.29.0 default pin. Upstream changed standalone auto_approve to true; /auto off persists prompting and --ask enables it for one run. Its hard denylist, filesystem protections and explicit manual/plan modes remain separate constraints. A remembered grant and a one-run autonomy flag have different persistence.
HarnessRouter’s driver at the stable tag makes a different integration decision: it sets permission_mode to accept-all while withholding disabled built-in and MCP tools from the native schema. Therefore the CE tool policy must be assessed at the exposed registry/schema boundary; do not rely on the standalone CLI showing an approval prompt.
| What to inspect | Why it matters |
|---|---|
| Enabled native tool schema | A disabled operation must not become available merely through prompt wording |
| MCP tool identity | Tool withholding must cover configured MCP names as well as built-ins |
| Live generator events | The adapter’s progressive stream comes from execution, not from reading a finished session file |
| Continued session state | A later task must own the intended persisted conversation |
A small acceptance case reads an allowed fixture, attempts a withheld operation and then continues to inspect the fixture. Capture tool declarations, execution events and resulting state. This page proposes that case; it does not claim a new run.
Use tool-surface coherence to compare declaration and enforcement, and session recovery for continuation ownership. The matching version numbers simplify reproduction, but provider and policy configuration still determine the actual result.
What shipped
Section titled “What shipped”PR #264, released in HarnessRouter v0.25.0, adds CheetahClaws 3.5.88 as the sixteenth base backend.
HarnessRouter drives the upstream agent loop in process rather than scraping terminal output. The driver re-emits live events as NDJSON and keeps provider routing, usage accounting and session recovery inside HarnessRouter’s adapter boundary.
Evidence boundary
Section titled “Evidence boundary”This proves HarnessRouter adapter support for CheetahClaws. It does not establish that the upstream CheetahClaws project natively implements or endorses UHP.
Integration notes
Section titled “Integration notes”The upstream CLI’s saved session file is not a progressive event stream, so HarnessRouter consumes the agent generator directly for live task events. Provider credentials route through HarnessRouter’s relay rather than being persisted into the CLI state.
Related reading
Section titled “Related reading”Use the HarnessRouter guide to distinguish backend selection from provider configuration, and adoption to interpret what adapter support establishes.