Skip to content
UHPUHPDeveloper Guide
Independent resource · Not affiliated with HarnessRouter · Site data checked 14 Sep 2026

Harness integration

Goose

Goose is now a released HarnessRouter backend while also exposing a first-party ACP server upstream. Those are two different interoperability surfaces.

Verified: UHP: 2026-09-12HarnessRouter stable: v0.17.1

Status first

Section titled “Status first”

Goose is now a released HarnessRouter backend. HarnessRouter PR #164 added goose as the eleventh built-in backend; the change shipped in v0.17.0 and remains in latest stable v0.17.1. At this cutoff the v0.17.1 tag and checked upstream main both resolve to 5637717816b5923c58bb3b1779e1ccab7359349f.

HarnessRouter pins Goose 1.50.0 for this adapter. Goose’s own latest observed stable release is also v1.50.0, published 8 September 2026.

This is HarnessRouter adapter support, not native UHP adoption by Goose. Upstream Goose separately has a first-party ACP surface; its own architecture material describes ACP as the new default client interface. Native ACP support does not imply native UHP support.

v0.17.1: hosted-sandbox temp files and failure fidelity

Section titled “v0.17.1: hosted-sandbox temp files and failure fidelity”

PR #174, released in v0.17.1, fixes the first material post-release Goose deployment defect. A Goose platform extension writes temporary files through std::env::temp_dir(). In the hosted sandbox, /tmp is denied, so Goose could print “goose is ready” and then fail every turn when that extension touched the blocked temp path.

HarnessRouter now sets TMPDIR to a workspace-owned temporary directory for Goose, matching the principle already used by its Codex runner. The same change improves failure evidence: a failed turn prefers the CLI’s actual trailing output over a generic <cli> exited N normalizer, and the gateway retains up to 2,000 characters of connection-error detail instead of 200 so panic/error context is not truncated away. The PR records 323 runner tests and 527 gateway tests passing.

These are HarnessRouter sandbox/runtime and failure-observability corrections. They do not change Goose’s wire protocol, ACP, UHP, or the UHP conformance denominator.

What HarnessRouter added

Section titled “What HarnessRouter added”

PR #164 integrates Goose end to end rather than treating it as a generic command passthrough.

  • Pinned binary installation. HarnessRouter installs the prebuilt Goose release asset and pins archive digests for the supported targets. An explicit HR_GOOSE_VERSION override requires the corresponding HR_GOOSE_SHA256 to remain verified; otherwise the installer says the override is unverified instead of silently skipping integrity checking.
  • Relay-backed model routing. Goose reaches models through its OpenAI-compatible Chat Completions provider pointed at HarnessRouter’s loopback relay. Because Goose splits that endpoint into OPENAI_HOST and OPENAI_BASE_PATH, the adapter splits the relay URL rather than passing one combined /v1 URL and producing a duplicated /v1/v1/chat/completions path.
  • Checkpointable state. GOOSE_PATH_ROOT is placed inside the HarnessRouter .harness/ state tree so Goose configuration, its session database and harness skills travel with checkpoint/recycle state while remaining outside the produced-file list.
  • Native stream normalization. The adapter handles Goose’s mixed stream schema: snake_case event tags such as message and complete, camelCase content blocks such as toolRequest and toolResponse, nested tool-call values, and Goose’s result/error shape.
  • Token accounting. Goose’s cache_write_input_tokens field is normalized instead of being dropped because the shared usage picker only recognizes the camelCase spelling.
  • Hard disabled-tool enforcement. The adapter uses Goose available_tools to remove disabled tools from the model-visible set. HarnessRouter explicitly avoids relying on permission.yaml here because GOOSE_MODE=auto bypasses that permission table.
  • Partial extension configuration. HarnessRouter only names the extensions it must restrict or add, preserving Goose defaults such as Skills, Todo and Analyze instead of accidentally disabling them by writing a complete replacement map.

Failure and resume fidelity

Section titled “Failure and resume fidelity”

The same merge includes several correctness fixes found while measuring the adapter.

Goose can turn some upstream provider failures into ordinary assistant prose followed by complete. HarnessRouter recognizes the pinned binary’s real error prefixes and converts them back into an error result instead of recording the turn as successfully completed and carrying the provider-error prose into later history.

Session existence is checked through Goose’s SQLite sessions table rather than searching raw database bytes for a session string. The regression coverage includes an uncheckpointed WAL case, so the check follows SQLite state rather than a brittle byte-pattern heuristic.

HarnessRouter’s relay also records the served model for CLIs that do not expose it themselves. The SSE reader carries a tail across 4096-byte read boundaries so a split model field is not silently missed. That relay evidence is what makes the Goose support-matrix rows substitution-checkable.

Current compatibility evidence

Section titled “Current compatibility evidence”

PR #164 records a dedicated Goose support-matrix pass dated 12 September 2026 across seven provider columns: TokenRouter, Vercel, OpenRouter, OpenAI, Azure, Anthropic and the hosted HarnessRouter provider. The merge notes say the Goose column ran 36 models, with 35 shipped after excluding claude-opus-5 because tool-using turns produced an empty response through Goose’s Chat Completions path. Five catalog candidates are explicitly listed as not yet run rather than being presented as measured.

The earlier candidate verification also records follow-up continuity, a model switch and switch-back, artifact byte equality, forced-recycle recall, skill/script execution, a genuinely absent disabled tool and a declared MCP server call. These are HarnessRouter implementation/runtime measurements under the stated test conditions. They are not UHP conformance, universal Goose/provider compatibility, or evidence that upstream Goose implements UHP.

Native ACP is a separate boundary

Section titled “Native ACP is a separate boundary”

Goose’s upstream architecture has independently standardized its client-facing surface around Agent Client Protocol (ACP). In the tagged v1.50.0 architecture article, Goose says ACP is its new default interface and describes the production-ready server with session persistence, extensions and streaming as complete. The official ACP registry/matrix also directly probes Goose 1.50.0; the site’s broader ACP comparison tracks that evidence separately.

That produces two simultaneous integration paths:

  1. Goose ↔ ACP client — upstream-native client/agent interoperability.
  2. Product ↔ UHP/HarnessRouter ↔ Goose — HarnessRouter adapts the Goose runtime behind the UHP-facing server boundary.

Neither path proves the other. A product can use Goose through HarnessRouter without speaking ACP to Goose directly, and Goose’s native ACP server does not make Goose a native UHP implementation.

UHP boundary

Section titled “UHP boundary”

UHP remains 2026-09-12 Draft with conformance package 2026.9.12. HarnessRouter v0.17.0/v0.17.1 change the reference implementation and released backend set; they do not publish another UHP protocol version, change the 74-check conformance denominator, or establish a standardized UHP↔ACP binding.

At this cutoff:

  • HarnessRouter stable: v0.17.1 — eleven released backends.
  • HarnessRouter checked main: 5637717816b5923c58bb3b1779e1ccab7359349f.
  • HarnessRouter Goose pin: 1.50.0.
  • Goose upstream stable: v1.50.0.
  • Native Goose ACP: verified upstream.
  • Native Goose UHP adoption: not established.

See HarnessRouter for the reference implementation boundary and UHP vs ACP for the client/agent protocol comparison.

Primary sources

Section titled “Primary sources”