UHP and Cline

Status first

Cline is now a released HarnessRouter backend. Pull request #51, “feat: Cline as the eighth backend, every claim measured first,” merged on 31 August 2026 at 35138ce and shipped in HarnessRouter v0.12.0, published the same day. The current latest HarnessRouter release observed is v0.12.1, also published 31 August.

HarnessRouter pins the Cline CLI to 3.0.60 for this adapter. The upstream Cline repository identifies its CLI package as @cline/cli version 3.0.60, Apache-2.0 licensed, and describes it as an autonomous coding-agent CLI. HarnessRouter installs the npm cline package at the pinned version and treats that exact binary behavior as the compatibility baseline for the adapter.

Caution

This is not native Cline adoption of UHP. The UHP server is HarnessRouter. HarnessRouter launches and adapts the Cline CLI behind its own UHP implementation. No primary Cline source reviewed for this page establishes that Cline itself implements, endorses or exposes UHP.

What HarnessRouter added

The integration maps Cline into the same complete-harness runner/gateway boundary used for the other HarnessRouter backends, while documenting several Cline-specific limits instead of pretending every backend has identical semantics.

• Headless execution: Cline 3.0.60 is driven through its --json mode. HarnessRouter parses the JSONL event stream and maps content/tool lifecycle events into its normalized harness event model.
• Tool events: tool calls are reconstructed from Cline content_start / content_end events and surfaced as tool-use/tool-result events rather than flattened into text.
• Streaming boundary: the adapter does not advertise token-level streaming. Text is emitted at Cline content-chunk completion boundaries because that is the behavior measured from the pinned CLI.
• Credential isolation: HarnessRouter routes Cline through its loopback relay and writes the CLI’s required provider settings without putting the real provider credential inside the sandbox. The adapter deliberately follows measured settings-file behavior instead of assuming environment variables are equivalent.
• Workspace durability: Cline’s HOME is redirected into the per-session HarnessRouter workspace so CLI state participates in the existing checkpoint/recovery model.
• Instructions: HarnessRouter uses the workspace AGENTS.md path for durable agent instructions after direct headless skill-directory injection did not produce reliable behavior in the measured CLI.
• Tool enforcement: the backend is classified with instruction-level restrictions rather than a backend-native per-tool hard deny. That is weaker than a native enforcement mechanism and should not be described as equivalent authorization.

Headless resume is deliberately not claimed

A material integration limit is Cline 3.0.60 headless resume. HarnessRouter’s live verification found that combining --json with an existing task/session id refused a new prompt in the tested forms. The adapter therefore does not wire a native Cline resume path and does not pretend the CLI can continue a headless conversation through --id.

Instead, HarnessRouter keeps the UHP/session conversation in its own durable turn records. On a Cline follow-up it builds a bounded transcript and prepends that history to the new runner prompt. The history window is explicitly capped, newest turns win the byte budget, and the user-facing stored turn remains the raw user message rather than the augmented runner prompt.

That is a HarnessRouter compensation layer, not native Cline session continuity. It preserves useful follow-up context while keeping the limitation visible to operators evaluating backend substitution.

Live verification and model surface

PR #51 records real gateway-backed verification rather than configuration-only wiring. The evidence includes a successful text turn, a tool-use turn that wrote and read a file with byte-exact verification, and model-routing checks through the loopback relay.

The final Cline model catalogue in the merge contains 22 live-verified models from a 24-candidate sweep. The two omitted candidates were intentionally left out after live failures on that Cline/relay surface rather than being advertised from an assumed provider catalogue. The merge also records cross-model follow-up verification through the gateway-owned conversation-history fallback.

This is strong functional backend evidence, but it is not a Cline-specific complete UHP conformance report. HarnessRouter’s generic recorded Full result measures the reference implementation as a whole; this guide does not silently restate that as a separate Cline-path 62/62 result without an exact path-specific run.

v0.12.1 hardens routing across the expanded backend set

HarnessRouter v0.12.1 follows the Cline release with PR #52. It adds glm-5.3 and glm-5.3-flash across the remaining compatible base harnesses, including Cline, and replaces a handwritten backend-inference chain with catalogue-derived routing.

That routing change matters because the old chain had already drifted: Qwen was missing, so a user-created Qwen harness using a model such as gpt-5.4 could fall through to Codex routing. The new logic derives backend identity from the base catalogue so adding another backend such as Cline does not require a second manually synchronized routing list. PR #52 reports a 20/20 live matrix covering all eight default backends plus both GLM models across six relay-backed harnesses.

This is HarnessRouter implementation hardening. It does not change UHP’s protocol version, create a UHP model-routing primitive, or establish native Cline UHP adoption.

What this means for UHP users

Cline expands the reference implementation’s substitution surface to eight released harness backends. The useful architectural lesson is not that all eight are behaviorally identical; it is that the UHP-facing server can normalize materially different runtime contracts while preserving the differences that matter — streaming granularity, native resume support, credential mechanics and tool-enforcement strength.

For production evaluation, treat Cline’s current HarnessRouter path as released and live-verified, but keep these boundaries explicit:

• no separate Cline-specific current 62/62 conformance report is claimed;
• no native Cline UHP implementation or endorsement is established;
• native Cline headless resume is not claimed for the pinned 3.0.60 adapter;
• HarnessRouter’s bounded transcript fallback is server-side continuity, not a Cline protocol guarantee.

Primary sources

• HarnessRouter PR #51 — Cline as the eighth backend
• HarnessRouter Cline merge 35138ce
• HarnessRouter v0.12.0 release
• HarnessRouter v0.12.1 release
• HarnessRouter PR #52 — GLM family and catalogue-derived routing
• Cline upstream repository
• Cline CLI 3.0.60 package definition