Skip to content
UHPUHPDeveloper Guide
Independent developer guide. Not affiliated with HarnessRouter or the official UHP project.

UHP and Cline

Cline first shipped as HarnessRouter's eighth backend in v0.12.0. That is a reference-implementation fact, not native UHP adoption by the Cline project.

Page reviewed 4 Oct 2026 Source and review policy

Historical UHP context: 2026-09-12HarnessRouter checked 4 Oct: v0.29.0

Test the CLI product, not a desktop or extension version

Section titled “Test the CLI product, not a desktop or extension version”

Cline publishes several products in one repository. The latest application-family review on 4 October identifies cli-v3.0.68 for the CLI, while desktop and SDK tags have different versions. HarnessRouter’s stable adapter still pins CLI 3.0.60; the newest team-state compaction and model-catalogue changes in 3.0.68 do not describe that binary.

RequirementDirect Cline pathHarnessRouter path
Editor/client permission promptsNative ACP negotiation and promptsAdapter policy plus the backend’s execution behavior
Machine-readable tool eventsThe installed CLI’s documented outputNormalized UHP stream and stored Response
Agent Plugins introduced after 3.0.60Check the matching native versionRequire explicit adapter/runtime upgrade evidence
A selected model appears in a pickerNative catalogue/account availabilityCE catalogue plus configured provider route

For a first UHP acceptance case, choose one allowed read-only tool and one deliberately disabled operation against a fixture. Verify that the allowed tool appears in execution evidence and the denied operation does not run. Cline’s content_start/content_end events matter because an answer containing a tool name is not itself a tool invocation.

If direct Anthropic calls fail with a 404, inspect the versioned relay-path fix below before changing authentication; a malformed API root and an invalid credential need different repairs. Tool-surface coherence helps compare model-facing declarations to the actual policy. Record the CLI version alongside the CE release instead of reporting only the Cline product name.

HarnessRouter integration, checked 4 October 2026: the v0.29.0 entrypoint retains the default pin Cline 3.0.60. This is source-verified adapter configuration, not a fresh runtime or provider test. HarnessRouter now has 20 released backends; the earlier counts and measurements below retain their dated scope.

Historical detail: the implementation narrative below preserves the 18 Sep 2026 source snapshot. Later upstream releases and HarnessRouter releases must not be inferred from that snapshot.

Source snapshot — 18 Sep 2026

Section titled “Source snapshot — 18 Sep 2026”

Cline is 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 HarnessRouter stable release is v0.18.1 / a27df946, published on GitHub 17 September 2026 at 19:09:51 UTC. Stable v0.18.1 has twelve built-in harness backends after Kimi Code CLI became backend kimi. Checked HarnessRouter main is de992987ea54bea406d12c283947f38e634988e5 after PR #208; it has the same twelve backends and differs from v0.18.1 only by the release-publication workflow correction at this cutoff.

HarnessRouter still pins the Cline CLI to 3.0.60 for this adapter. Cline has since published CLI v3.0.62 on 15 September 2026 at 06:04:39 UTC, after v3.0.61, so the reference adapter is now two upstream CLI releases behind. Exact checks at HarnessRouter v0.18.1 still install cline@${HR_CLINE_VERSION:-3.0.60} and current main has not changed that coordinate. Behavior introduced only in 3.0.61 or 3.0.62 therefore cannot be projected onto the released UHP→Cline adapter until the pin is moved and reverified.

The same upstream Cline CLI also natively implements ACP. Tagged cli-v3.0.60 already documents cline --acp, launched by an ACP client over stdio, and exposes client-driven authentication, Plan/Act switching, model/provider selection, permission prompts, session loading, images and organization switching. This is first-party Cline ACP support, not an adapter around Cline.

Cline CLI 3.0.62 also adds first-party Agent Plugins handling independently of UHP. Packages under ~/.agents/plugins/* are discovered and validated, plugin skills are exposed through the skills tool as plugin-name:skill-name, and plugin MCP servers start without rewriting cline_mcp_settings.json. Cline deliberately does not scan workspace .agents/plugins directories, so merely opening a repository cannot implicitly start repository-controlled MCP servers. This is upstream Cline host behavior in 3.0.62; HarnessRouter’s pinned 3.0.60 backend does not inherit it.

HarnessRouter PR #71, released in v0.13.5, wires Google AI Studio to the existing Cline backend through Gemini’s OpenAI-compatible Chat Completions surface. v0.13.8 then repairs Google provider-catalog/saveability and shared Google unknown-field retry behavior. These are HarnessRouter provider-routing facts, not a Cline CLI upgrade, fresh Cline-specific conformance run, ninth backend, UHP change or native Cline UHP adoption signal.

v0.13.10: direct Anthropic relay path is corrected

Section titled “v0.13.10: direct Anthropic relay path is corrected”

PR #86 is directly relevant to the Cline adapter because Cline reaches provider credentials through HarnessRouter’s loopback relay. The 6 September support matrix found Cline failing every first turn with Not Found on a direct Anthropic key. The relay had joined Cline’s resource path onto an unversioned https://api.anthropic.com base, producing a route Anthropic answered with 404.

Released v0.13.10 appends /v1 when the relay base has no API-version path, preserves already-versioned bases such as /v1 or /v1beta/openai, and leaves AWS hosts to the Bedrock-specific path builder. PR #87 subsequently added support-matrix validation hardening. Fresh v0.18.1 and current-main checks still show the Cline adapter pinned to 3.0.60.

This is released HarnessRouter relay/provider compatibility work, not a change to Cline 3.0.60, ACP, UHP, the backend count or native-adoption status.

What HarnessRouter added

Section titled “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.

One harness, three distinct interoperability surfaces

Section titled “One harness, three distinct interoperability surfaces”

Cline is a useful concrete example of why harness identity and protocol identity should not be conflated. The upstream project now exposes multiple independent integration surfaces whose maturity and version coordinates must be tracked separately:

  • Direct ACP: an editor or other ACP client launches cline --acp and talks to Cline over the Agent Client Protocol. Cline’s own tagged documentation says ACP sessions can be loaded after restart and exposes ACP-native permission/configuration surfaces.
  • Native Agent Plugins in Cline 3.0.62: Cline’s own host discovers user-level packages under ~/.agents/plugins/*, validates them, exposes plugin skills and starts declared MCP servers. This is package/host integration, not an execution protocol and not UHP adoption.
  • UHP through HarnessRouter: a UHP client talks to HarnessRouter, which launches the pinned Cline 3.0.60 through --json and normalizes its output into UHP task/session semantics. HarnessRouter’s optional Harness Plugins implementation is server-owned UHP behavior and is distinct from Cline 3.0.62’s native Agent Plugins host path.

HarnessRouter does not use cline --acp for the released backend. Therefore Cline’s direct ACP session-loading contract does not erase the separately measured --json headless-resume limitation below. Likewise, Cline 3.0.62 gaining native Agent Plugins support does not silently change a HarnessRouter backend that still installs 3.0.60. These are interface- and version-dependent runtime behaviors.

Upstream 3.0.61 added a bounded 10-second connection budget for unreachable remote SSE/Streamable HTTP MCP servers, fixed empty model-capability lists incorrectly disabling tools/images, propagated session aborts to delegated subagents/teammates, and made Hub replacement drain active sessions before replacing an older Hub. Upstream 3.0.62 then adds the Agent Plugins behavior above and other runtime changes including bounded retry for transient provider failures before any output is streamed, checkpoint-indexing work for large untracked workspaces, and removal of a surviving vulnerable undici@5.29.0 dependency in favor of 7.x. These are upstream Cline behaviors; HarnessRouter v0.18.1 and current main remain pinned to 3.0.60, so this guide does not project them onto the released UHP adapter.

Headless resume is deliberately not claimed

Section titled “Headless resume is deliberately not claimed”

A material integration limit is Cline 3.0.60 headless resume on the HarnessRouter --json path. 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 this headless interface can continue a 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. It should not be generalized to Cline’s separate ACP interface, whose tagged documentation explicitly supports session loading.

Live verification and model surface

Section titled “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 the current 74-check suite result as a separate Cline-path 74/74 run without exact path-specific evidence.

v0.12.1 hardens routing across the expanded backend set

Section titled “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. Later releases through v0.18.1 retain the Cline 3.0.60 compatibility baseline. Stable v0.18.1 and current main both have twelve released backends at this cutoff.

What this means for UHP users

Section titled “What this means for UHP users”

Cline originally expanded the reference implementation’s substitution surface to eight released harness backends. Current stable HarnessRouter v0.18.1 has twelve built-in backends, and current main has the same twelve after PR #208’s publication-only workflow correction. Cline also provides a clean example of one harness exposing native interoperability/package surfaces while being adapted behind a different outer protocol. The useful architectural lesson is not that the interfaces are behaviorally identical; it is that each boundary and pinned version must be measured on its own terms.

For production evaluation, treat Cline’s HarnessRouter path as released and live-verified at its pinned compatibility coordinate, but keep these boundaries explicit:

  • no separate Cline-specific current 74/74 conformance report is claimed;
  • Cline natively implements ACP, but no native Cline UHP implementation or endorsement is established;
  • Cline CLI 3.0.62 natively consumes Agent Plugins packages, but HarnessRouter still pins 3.0.60; native Cline Agent Plugins behavior is therefore not evidence that the pinned UHP adapter has upgraded to that host path;
  • native Cline headless resume is not claimed for the pinned 3.0.60 --json adapter path; direct ACP session loading is a separate interface;
  • HarnessRouter’s bounded transcript fallback is server-side continuity, not a Cline protocol guarantee;
  • upstream CLI 3.0.61 and 3.0.62 fixes are not attributed to HarnessRouter while its released/current-main adapter remains pinned to 3.0.60.

Primary sources

Section titled “Primary sources”