Harness integration
UHP and OpenCode
OpenCode is now integrated as a HarnessRouter backend on upstream main. That is a reference-implementation fact, not native UHP adoption by the OpenCode project.
Status first
Section titled “Status first”HarnessRouter upstream main now contains an OpenCode backend, but that work is not in the latest tagged HarnessRouter release. Pull request #29, “feat: OpenCode backend,” merged on 26 August 2026 at commit f0d5661. The latest official HarnessRouter tag observed remains v0.9.1 from 24 August 2026.
The upstream OpenCode project is the MIT-licensed open-source coding agent at anomalyco/opencode. HarnessRouter’s integration was developed against the released OpenCode v1.18.23 configuration contract during the pre-merge fixes.
What HarnessRouter added
Section titled “What HarnessRouter added”The merged backend gives HarnessRouter a sixth harness runtime alongside Claude Code, Codex, Hermes, Pi and DeepSeek Harness. The current main installer/default-backend path includes opencode, and the gateway registers an OpenCode base so the console and UHP harness catalogue can route tasks to it.
The runner integration uses OpenCode’s non-interactive JSON event surface and translates those events into HarnessRouter’s existing task/session pipeline. During implementation, HarnessRouter added or corrected several backend-specific details:
- Structured execution: OpenCode runs through its JSON-formatted CLI stream rather than terminal scraping.
- Session continuation: the adapter carries OpenCode session identity so UHP continuation through
previous_response_idcan remain on the same OpenCode conversation. - MCP and skills: HarnessRouter materializes configured MCP servers and skill paths into OpenCode’s released configuration shape. OpenCode receives harness instructions through
AGENTS.md, which is the instruction filename its loader reads. - Tool enforcement: HarnessRouter maps disabled tools into OpenCode’s native permission model, using hard deny semantics rather than relying only on model instructions.
- Plugin isolation: the runner uses OpenCode’s pure-mode path so workspace plugin configuration cannot silently expand the harness execution surface.
- Model/provider routing: the merged gateway exposes OpenCode across the multi-family model catalogue supported by HarnessRouter’s serving paths rather than pinning the backend to a single model family.
These are HarnessRouter implementation choices. UHP itself does not require an OpenCode CLI, OpenCode configuration file, AGENTS.md, a specific permission syntax, or any particular model catalogue.
Evidence of a working turn
Section titled “Evidence of a working turn”Before the backend merge, HarnessRouter recorded an end-to-end correction for two failures that had prevented reliable OpenCode execution: the child process inherited a stale PWD, and built-in harness ids could fall through to model-name-based backend guessing. After fixing both, the upstream commit records a live console/BFF check where:
- an OpenCode turn completed on
gpt-5.4; and - a second turn completed through
previous_response_id, preserving session continuity.
The same commit reports the repository test suite passing at that point.
Released vs unreleased state
Section titled “Released vs unreleased state”| Question | Verified answer |
|---|---|
Is OpenCode in HarnessRouter upstream main? | Yes. PR #29 merged on 26 Aug 2026. |
Is OpenCode in the latest HarnessRouter tag v0.9.1? | No. v0.9.1 predates the merge. |
| Has UHP itself changed? | No. The current protocol changelog still lists only 2026-08-11. |
| Is there OpenCode-specific Full 52/52 evidence published? | Not established by the sources reviewed for this page. |
| Does this prove OpenCode adopted UHP natively? | No. It proves HarnessRouter integration. |
Why this matters
Section titled “Why this matters”OpenCode broadens the reference implementation’s harness-substitution surface beyond the five backends in the latest tagged release. It is also a useful example of why UHP and backend integration must be separated conceptually: clients keep speaking the same UHP task/session/file contract while HarnessRouter performs backend-specific translation, configuration, permissions and event normalization underneath.
Until the work appears in a HarnessRouter release tag, production users should treat it as merged unreleased main-branch functionality, not as a capability of the v0.9.1 image.
Related pages
Section titled “Related pages”Read HarnessRouter Community Edition for the implementation-wide view, the release tracker for released-versus-unreleased status, and the adoption tracker for the difference between integration and native UHP support.