Harness integration
UHP and Qwen Code
Qwen Code is now integrated as HarnessRouter's seventh backend on upstream main. That is a reference-implementation fact, not native UHP adoption by the Qwen Code project.
Status first
Section titled “Status first”HarnessRouter upstream main now contains a Qwen Code backend, but that work is not in the latest tagged HarnessRouter release. Pull request #31, “feat: Qwen Code backend,” merged on 27 August 2026 at commit 4e4a1a9. The latest official HarnessRouter tag observed remains v0.9.1 from 24 August 2026.
HarnessRouter describes Qwen Code as its seventh backend, after Claude Code, Codex, Hermes, Pi, DeepSeek Harness and the previously merged OpenCode backend. The PR records binary-first verification against a shipped Qwen Code 0.22.1 build. Separately, the current official Qwen Code GitHub release observed is v0.22.2, published 26 August 2026; this guide does not assume the HarnessRouter test matrix automatically covers that newer build.
What HarnessRouter added
Section titled “What HarnessRouter added”The merged runner/gateway integration maps Qwen Code into the same backend contract HarnessRouter uses for other complete coding harnesses:
- Structured execution: Qwen Code runs headlessly and emits
stream-json. HarnessRouter’s verification found that the emitted stream is Claude-shaped enough to reuse the existing Claude passthrough normalizer rather than adding a separate event-mapping layer; token streaming is preserved. - Session continuation: Qwen Code resumes a prior session with its native resume argument. The integration pins
--auth-type openaion resumed turns because the upstream CLI otherwise prompts for authentication again in the tested headless path. - Credential handling: the runner supplies
OPENAI_API_KEYandOPENAI_BASE_URLthrough the process environment; the PR’s verification explicitly checks that the generated Qwen settings file contains no provider key at rest. - MCP and instructions: configured MCP servers are materialized through Qwen Code’s
mcpServerssettings shape, while harness instructions use the upstreamQWEN.mdinstruction file. - Workspace/session durability: Qwen Code’s home is redirected into the per-session
.harness/hometree so settings, skills and resumable session state participate in HarnessRouter’s existing workspace/checkpoint lifecycle. - Tool restrictions: the current integration uses instruction-level enforcement for the Qwen backend rather than claiming a backend-native per-tool hard kill switch. That is weaker than the native deny semantics HarnessRouter can use for some other backends and should not be described as equivalent enforcement.
- Provider routing: current
mainroutes Qwen Code through several existing provider families and also adds Qwen to the unreleased Custom OpenAI Chat Completions compatibility set. The Custom Anthropic Messages set remains separate and does not include Qwen Code in the merged PR.
These are HarnessRouter implementation choices. UHP itself does not require the Qwen CLI, QWEN.md, Qwen settings files, a particular auth type, or any model/provider catalogue.
Evidence of a working backend
Section titled “Evidence of a working backend”The PR records three kinds of functional verification rather than configuration-only wiring:
- A fresh headless Qwen Code turn completed successfully with return code 0 and a normal result event.
- A live relay-backed tool-use turn wrote and read a file, exercising the agent’s real tool path rather than a text-only response.
- Resume testing reused the same Qwen session identifier after pinning the non-interactive auth type.
The merge also reports 148 runner tests passing plus clean static/type/shell checks at that point.
Upstream Qwen Code context
Section titled “Upstream Qwen Code context”The upstream Qwen Code project describes itself as an open-source terminal coding agent with headless execution, session management, MCP, subagents/agent teams, skills and multiple model-provider API families. Its current README also documents an experimental qwen serve daemon using ACP and a separate ACP delegation path through Qwen Code Claw.
Those upstream capabilities help explain why Qwen Code is a plausible complete-harness backend, but they remain Qwen Code behavior, not UHP behavior. HarnessRouter’s UHP adapter is the interoperability layer covered on this page.
Released vs unreleased state
Section titled “Released vs unreleased state”| Question | Verified answer |
|---|---|
Is Qwen Code in HarnessRouter upstream main? | Yes. PR #31 merged on 27 Aug 2026 at 4e4a1a9. |
Is Qwen Code 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 Qwen-specific Full 52/52 evidence published? | Not established by the sources reviewed for this page. |
| Does this prove Qwen Code adopted UHP natively? | No. It proves HarnessRouter integration. |
Why this matters
Section titled “Why this matters”Qwen Code broadens the reference implementation’s harness-substitution surface to seven merged backends while keeping the external UHP client contract unchanged. It also demonstrates another important implementation distinction: a backend can be functionally integrated and tested without automatically inheriting a separate backend-specific UHP conformance claim.
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, UHP and OpenCode for the other post-v0.9.1 backend, and the adoption tracker for the difference between integration and native UHP support.