Independent developer guide. Not affiliated with HarnessRouter or the official UHP project.

Qwen Live Harness: setup, backends and privacy

Qwen Live Harness adds realtime voice and visual interaction to a desktop, with optional background coding agents, proactive monitors and local memory. Start with the current standalone package and the services it actually needs.

Page reviewed 4 Oct 2026 Source and review policy

Current guidance and dated source history

Recover configuration and stop the resource you actually own

The current standalone configuration guide treats JSON examples as fragments to merge, not replacements for your complete file. This matters when changing a backend or region: replacing config.json with a short sample can discard Memory, permissions and other working connections.

Identify the active standalone data/config directory before editing; do not assume the old ~/.qwen/live directory is current.
Change only the relevant fields, keeping one copy of each configuration section.
Align the realtime endpoint/key and region-specific models/voice IDs. Check the launch environment: QWEN_LIVE_HARNESS_REALTIME_ENDPOINT overrides the file’s endpoint, so a saved region can appear unchanged.
Restart through the installed-release or source-development launch path you actually use, then check realtime and background readiness separately.

The daemon guide separates call and application lifetimes:

Action	Expected ownership scope
End the call	Ends realtime interaction and Proactive capture; delegated jobs may continue
Quit the full application	Cleans up daemon-owned resources, ACP children and Live-managed Qwen Serve
Connect an existing service/terminal	Does not transfer ownership of that independently running process
Edit source-development configuration	Does not create the installed-release `run/runtime.json` startup record

Use the job’s own result/control evidence when deciding whether background work finished. A disconnected microphone, ended voice call or playback receipt is not that result. If a service operation has an uncertain outcome, inspect its state before creating a duplicate; the voice-cloning guide explicitly applies that rule when creation succeeded but local save/confirmation failed.

Control-delivery evidence explains admission versus outcome; session recovery explains why reconnecting to the right owner matters. These are source-derived recovery steps, not tested desktop/device behavior.

Start with the current project

Use qwen-live-harness from QwenLM/Qwen-Live-Harness. The full desktop experience currently requires macOS and Node.js 22.13 or newer. Windows and Linux desktop support are still in progress in the reviewed README. The Node daemon’s existence is not proof of a supported Linux desktop setup.

The naming has real history. The daemon development guide explicitly traces the standalone snapshot to Qwen Code PR #11369, commit f649d65d. Earlier coverage of @qwen-code/qwen-live therefore describes an ancestor, not the current installation command. Earlier data is not automatically migrated; the new default directory is ~/.qwen-live-harness. The Host release qwen-live-harness-host-v1.0.0, Qwen Code CLI releases and the old 0.1.0 daemon source package are different version lines.

Prerequisites and first launch

Requirement	What to prepare
Desktop	macOS, Node.js 22.13+, npm, microphone; camera or screen permission only for the visual input you choose
Realtime service	DashScope key authorized for the Qwen Omni Realtime and text models you need
Region	Choose Beijing or Singapore to match the region where the key was created; keys are not interchangeable
Background work	Optional installed and authenticated harness; its provider credentials are separate from Live’s realtime key
Source development	Also Xcode Command Line Tools and the Host dependencies; follow the source guide instead of mixing launch methods

The upstream installed-package workflow is:

node --version
npm --version
npm install -g qwen-live-harness
qwen-live-harness init
qwen-live-harness

The wizard selects language, backend, realtime model, key region and Memory. Grant the OS permissions requested for your chosen devices, then confirm connection and device readiness. These commands were checked against the pinned README; this guide did not install the desktop app, send audio or spend model credits.

Choose the background connection

Microphone / selected visual source
                │
           Electron Host
                │ local WebSocket
           Live daemon ───── model APIs
                │
      optional background connection
                ├── Qwen Serve (REST/SSE)
                └── ACP agent or ACP adapter

Qwen Code can use a Live-managed local Serve, an existing user-owned Serve, or native ACP. Codex and Claude Code use the named ACP adapters documented upstream; those adapters may download dependencies through npx on first use. Existing Qwen terminals use a separate peer discovery and authorization path. Discovering a terminal does not grant control over it. These connection modes are documented in the backend guide.

Choose no background harness if you only need the realtime conversation, visual analysis, search, Proactive or Memory. File edits and command execution need a suitable authenticated backend. A voice reply alone does not prove that a delegated coding job finished: inspect the attributed task result in Subagents.

Privacy and troubleshooting

Realtime connection fails: check the selected region, key permissions and model availability before changing backend credentials.
Conversation works but delegation fails: check that the selected harness is installed, authenticated and reachable through its chosen adapter.
No microphone or visual input: check the selected device and macOS permissions. Enable only the capture mode you intend.
Memory is local but data leaves the machine: local libraries store memories, while consolidation, embeddings and optional visual analysis use configured model APIs. Local storage is not offline inference.
Old setup appears missing: the standalone directory changed and migration is not automatic. Preserve the old directory before following current configuration guidance.
Sharing diagnostics: inspect logs first; upstream warns they may contain sensitive audio, video and conversations.

See the configuration guide for settings. Live is a harness-composition system; the reviewed sources do not establish native UHP support. For that distinct integration, use Qwen Code through HarnessRouter or compare ACP with UHP.

Historical source notes — baseline reviewed 15 Sep 2026

The following evidence preserves the earlier review and its links. “Current”, “stable” and “main” inside this section refer to that historical cutoff; they are not new release or compatibility claims. Use the guidance above for the current scope.

Status first

Qwen Code pull request #10367, merged on 1 September 2026 at commit 8290c81e, added packages/qwen-live: an independently versioned standalone voice daemon that extracts the Live voice-control loop from the qwen serve process.

The architecture materially advanced twice on 2 September 2026. Pull request #10617, merged as 7bd939ec, ships roadmap milestone M4: a generic AcpAdaptor plus multi-backend routing. Pull request #10769, merged as 829385a1, then ships the delivered part of M5: Live Host protocol v7 playback receipts plus an interactive qwen-live init setup wizard.

Qwen Code stable v0.23.0, published 3 September 2026 at tag commit 98a9c964, explicitly includes all three Qwen Live PRs (#10367, #10617 and #10769) in its release notes. That M4/M5 implementation is therefore shipped stable behavior rather than only moving-main evidence.

The standalone line then advanced materially through Qwen Code PR #11369, merged 11 September 2026 at 03:13:30 UTC as f649d65d. It upgrades the paired Host contract to protocol v9 and adds selectable Screen/Camera input, On Demand/Live Feed capture, isolated text-only proactive monitors, local multi-library Memory, persistent desktop controls and a Subagents view. The PR itself explicitly excluded release/npm publication at merge time, so this site initially tracked the change as unreleased current-main evidence. Qwen Code stable v0.23.4, published 14 September 2026 at 15:20:21 UTC with tag commit fdcd7c27, now includes PR #11369 in its release notes. The protocol-v9 visual/proactive/Memory line is therefore carried by stable Qwen Code v0.23.4, while the standalone @qwen-code/qwen-live package remains separately versioned.

Post-release Qwen current main has now advanced to 7157cdea7dfac69b9f3c883cae4f57c29ad3501c through PR #11636, merged 14 September 2026 at 22:45:46 UTC. That unreleased change gives background-result processing an explicit execution identity across the ACP Session, daemon bridge, SDK, Web Shell and Qwen Live adaptor. Qwen Live now distinguishes a background-only automatic execution from a foreground orchestrator job when it attaches to a session, excludes background-stamped updates from foreground answer collection, refuses to treat a background terminal as an unrelated job completion, and queues a new handoff as a foreground prompt when only an automatic execution is active because its job receipt requires a foreground terminal. This is current-main Qwen host/runtime behavior, not stable v0.23.4, not an ACP wire revision and not a UHP primitive.

The standalone package itself still has version @qwen-code/qwen-live 0.1.0 both at the v0.23.4 tag and checked Qwen main 7157cdea. The package requires Node.js >=22.13, includes the Qwen SDK dependency used by the expanded Live surface, and remains separately versioned from the Qwen Code application release line.

The M3 dependency boundary also changed earlier through Qwen Code PR #11560, merged 10 September 2026 at 22:13:39 UTC as af4dece3. It adds @qwen-code/sdk/peer and explicitly states that it unblocks issue #10118 M3. That peer endpoint is now also carried by stable Qwen Code v0.23.4, but Qwen Live’s own M3 wiring remains separate work; the dependency landing is not evidence that user-owned terminal-session orchestration is already shipped in qwen-live.

Architecture

Qwen Live separates the voice front end from the coding-agent backend:

Live Host ↔ Qwen Live: the v0.23.4 source carrier and current source speak Live Host WebSocket protocol v9 and publish the discovery file at ~/.qwen/live/daemon.json. Protocol v9 carries call epoch/output identity and end-of-stream playback acknowledgement so stale or foreign receipts cannot release a newer delivery queue.
Realtime voice: Qwen Live uses the DashScope realtime voice surface; current configuration defaults identify qwen3.5-omni-plus-realtime.
Visual input: current source can select Screen or Camera and choose On Demand or Live Feed capture. On Demand preserves the explicit appshot continuation path rather than silently converting a visual question into continuous observation.
Proactive observation: monitor sessions are isolated text-only DashScope sessions with no tool authority of their own. Ordered notifications return through the foreground delivery path; ending the voice call stops monitors while delegated coding work can continue reporting status.
Local Memory: multi-library Memory stores dialogue-derived state locally under the Qwen Live data directory; current documentation says raw audio and camera frames are not persisted as memory records. Selected evidence/context can still be sent to the configured consolidation/model service when Memory is enabled.
Backend registry: one configured backend is the default and additional named backends can coexist. A failed default-backend preflight aborts startup; a failed secondary backend is marked unavailable without taking down the daemon.
Qwen Code backend: QwenCodeAdaptor drives a running qwen serve daemon over its REST/SSE surface.
Generic ACP backend: AcpAdaptor spawns a configured ACP agent as a JSON-RPC-over-stdio child. One child process is used per configured ACP backend and multiplexes the sessions created through that adaptor.
Decoupled lifetimes: the Live session owns the realtime conversation and its JSONL log; backend coding sessions are separately managed resources.

The backend handle carries its adaptor identity, and BackendRegistry.adaptorFor() routes by that owner rather than guessing. This makes backend identity part of the session-control boundary when multiple harnesses coexist.

Receipt-style control tools

The base voice-model surface retains seven orchestration tools:

Tool	Role
`handoff`	Send work or a follow-up instruction to a managed coding session.
`session_list`	Enumerate sessions across available backend adaptors; rows identify their backend.
`session_create`	Create a backend session, optionally selecting a named backend, and return a handle.
`session_monitor`	Request current task/session progress.
`session_stop`	Stop managed work.
`respond_permission`	Relay a user permission decision to the owning backend session.
`appshot`	Request one frame from the currently selected visual source through the capture channel.

Current source can add six optional Proactive receipt tools: create_proactive_monitor, create_live_narration, create_proactive_timer, update_proactive_task, cancel_proactive_task, and list_proactive_tasks. The tool-definition contract explicitly keeps long-running results out of synchronous tool replies; monitors/timers return receipts and later inject their notifications. Synthetic proactive notifications do not inherit ordinary foreground tool authority.

The tools remain deliberately receipt-oriented. Completion, progress, errors and permission requests return through a separate injector instead of forcing the model to synchronously wait for every backend operation. The dispatcher answers every call, including a pending receipt on timeout while the underlying operation continues, so a delayed operation is not automatically retried as a second command.

ACP routing, prompt admission and steering

The generic ACP path introduces explicit transport constraints rather than pretending every backend behaves like Qwen Code:

ACP session/prompt is treated as preemptive, so Qwen Live never sends a second prompt directly while a turn is already in flight. Busy follow-ups are either admitted as supported steering or queued for continuation.
Qwen Code’s ACP extension craft/drainMidTurnQueue can pull queued steering between tool batches. Qwen Live reports steering as queued until a backend has actually demonstrated that drain path; a non-Qwen ACP agent can therefore degrade without a false native-steering claim.
Backend capability flags have real consumers: image blocks are stripped with a receipt note for image-incapable backends, unsupported steering is suppressed/degraded, and non-streaming backends do not start the event pump.
QWEN_LIVE_BACKENDS can supply the backend array through JSON; file configuration is the next source, while legacy single-qwen serve spellings synthesize the prior one-backend configuration.

This is a genuine multi-harness control-plane implementation first shipped inside Qwen Code v0.23.0, but the genericity boundary is ACP: a non-ACP harness still needs another adaptor rather than becoming automatically compatible.

Post-`v0.23.4` current main: automatic background execution is not a foreground job

PR #11636 closes a lifecycle ambiguity that matters directly to Qwen Live. Qwen’s daemon can process a completed background/subagent result in an automatic execution after the originating user prompt has settled. That work now has its own execution identity rather than borrowing the preceding foreground prompt identity or appearing simply idle.

For Qwen Live, the distinction is operational rather than cosmetic. A background-stamped update does not adopt the active orchestrator job; a background terminal cannot satisfy that job’s completion receipt; and foreground answer collection excludes background status/chunks. If Live attaches while only an automatic execution is active, it records that background state separately. A new handoff is queued as a foreground prompt rather than silently steering the automatic execution, because the Live job contract needs the foreground terminal that proves the requested handoff completed. Background-only execution can still use the underlying Qwen mid-turn machinery where appropriate, but its lifecycle cannot impersonate foreground ownership.

The same current-main design retains pending background results when a user stops execution, makes start admission idempotent/retry-bounded, rejects stale end events that do not match the active execution, and separates hasRunningBackgroundTasks from hasActivePrompt. These are Qwen daemon/ACP-host lifecycle semantics. They do not add an ACP method, change ACP v1, define a UHP Task state, or establish that HarnessRouter’s CLI-based Qwen adapter uses this daemon path.

Guided backend setup

M5 adds qwen-live init as an explicit first-run path instead of requiring users to hand-author multi-backend configuration.

The wizard scans PATH for supported coding agents — currently qodercli, qwen, gemini, claude, and codex — using version probes and resolves the selected executable to an absolute path. Native ACP agents use their own executable; Claude Code and Codex are configured through their ACP adapter packages. The wizard then lets the user choose a default backend, add additional backends, supply or reuse a DashScope realtime API key, and choose a default working directory. PR #11369, now carried by stable Qwen Code v0.23.4, extends initialization with English/Simplified Chinese selection and optional Memory configuration, including the consolidation model. On macOS it can check/install the Live Host application. The resulting ~/.qwen-live/config.json is written atomically with mode 0600.

The current README’s supported-backend table distinguishes native ACP entry points (qodercli --acp, qwen --acp, Gemini’s experimental ACP mode) from adapter-based Claude/Codex paths and keeps qwen serve as the legacy Qwen-specific REST/SSE backend. That is Qwen Live product configuration, not a claim that those products implement UHP or that every backend has equivalent runtime capabilities.

Stable `v0.23.4` visual, proactive and Memory boundary

PR #11369 adds three capabilities that are coupled to the standalone Host/daemon contract but remain distinct authority and persistence domains. The code is now carried by stable Qwen Code v0.23.4; the package-level qwen-live version remains 0.1.0.

Visual capture is user-source-selectable rather than a generic hidden screen feed. Screen and Camera are separate sources; On Demand and Live Feed are separate capture modes. Camera preview visibility does not itself disable camera input, and selecting a source drives the relevant permission request. The existing appshot flow remains the explicit one-frame continuation path for current-scene questions.

Proactive monitors run in isolated realtime sessions configured with no tools and tool_choice: none. The foreground model exposes receipt tools to create/update/cancel/list monitors, narration and timers, but notification delivery is ordered back through the foreground session and synthetic notifications are not allowed to mint ordinary user-turn tool authority. Monitors stop with the call, while backend harness jobs can remain alive and continue status delivery after the call ends.

Memory is enabled by default in current source and supports multiple local libraries. The recorder separates genuine dialogue from synthetic Proactive/backend/repair turns; Qwen’s design notes state that raw audio and camera frames are not persisted as Memory records. Same-library consolidation is serialized, configuration writes remain atomic/private, and PR #11369 includes a fix for updating Memory preferences when config.json contains a UTF-8 BOM. Memory is a Qwen Live product feature, not a portable agent-memory protocol or UHP session-memory primitive.

The same change adds persistent draggable Host controls, language/theme settings, explicit input/output mute state, camera preview, a compact Subagents view for monitors/delegated harness work, and an Open config.json action that opens the connected daemon’s actual configuration without creating or overwriting it. Input mute releases the capture device; provider PCM is resampled through Web Audio using the selected/default output-device clock.

Permission boundary

Qwen Live turns backend permission requests into spoken questions and returns the user’s choice through respond_permission. The implementation selects among options actually offered by the backend rather than inventing an authorization outcome.

M4 uncovered a particularly important boundary for Qwen’s own ACP mode: new Qwen ACP sessions default to AUTO approval, which would silently allow actions and bypass the voice product’s permission relay. AcpAdaptor.createSession() therefore best-effort sets new sessions to the asking/default mode with session/set_mode default. ACP agents that do not implement that mode change keep their own default behavior.

The existing Qwen Code adaptor’s local allow_always experience remains a one-shot backend vote backed by a local TTL rule narrowed to the exact normalized command; it is not a new permanent permission primitive in qwen serve or ACP.

Result injection and playback confirmation

Backend events are fed into the live conversation through an injector that waits for a safe insertion window. It accounts for voice activity and an in-flight realtime response, batches related items, throttles progress and drops stale progress when the user barges in. Permission items are prioritized ahead of ordinary context so a blocked backend does not lose its authorization request behind status chatter.

Stable M5 introduced Host-originated playback receipts in protocol v7, replacing a byte-volume estimate. PR #11369 advances the paired contract to protocol v9 with call epoch plus output identity and an end-of-stream acknowledgement. Completion is accepted only for the matching trusted Host/output generation after the audio stream has actually drained; stale or foreign receipts do not release queued foreground/proactive delivery. That v9 code is now carried by stable Qwen Code v0.23.4.

The v9 boundary must not be projected backward into Qwen Code v0.23.0. A matching daemon and Host build are required for the newer contract. PR #11369 itself did not publish a release or installer at merge time; Qwen Code v0.23.4 later promotes the code into the stable application release line, while the standalone qwen-live package remains version 0.1.0.

That user-facing control plane is independent from the backend transport. Qwen Code events from qwen serve and normalized ACP events converge on the same BackendEvent model, while adaptor-specific thought/plan noise can be omitted from voice injection.

M3 dependency boundary: external peer SDK now exists

Qwen Code PR #11560 changes the status of a major M3 prerequisite without making M3 itself complete. The opt-in @qwen-code/sdk/peer subpath is a standalone implementation of Qwen’s cross-session protocol for a non-Qwen process — explicitly including a voice front end, relay or build watcher. PeerEndpoint.start({ name }) binds an inbox and publishes an external session record so Qwen sessions can discover it; the SDK can list and address sessions, receive messages and track receipt state transitions.

Upstream deliberately implemented the module from the published Cross-Session Protocol using Node built-ins rather than wrapping Qwen Code core. A conformance suite exercises both implementations in both directions and requires agreement on registry/inbox behavior, framing, authentication, identity derivation and published limits. The implementation review also closed a bearer-token hazard: a trusted-controller token is now sent only when the caller marks the send controller: true, and a receiver’s agents.crossSessionInbound policy remains authoritative. Linux requires procStart and pidNs identity data; Windows named-pipe support is not yet implemented.

The PR body explicitly marks this work as “Unblocks #10118 M3.” Stable Qwen Code v0.23.4 now carries the peer SDK, but that is still a dependency-state change rather than evidence that packages/qwen-live has adopted PeerEndpoint or that M3’s session_list aggregation, live virtual-session registration and handoff to user-owned terminal sessions are shipped. The site therefore distinguishes dependency available from Qwen Live M3 integrated.

Crash and continuity boundary

The generic ACP adaptor deliberately does not claim portable session recovery. Its tracked sessions live in the spawned child’s memory. If that child exits, Qwen Live cancels parked permissions, fails the busy turn, closes the sessions from that generation and lazily respawns a fresh child for later session creation. A stale handle is rejected rather than silently rebound to a different process generation.

That is a meaningful limitation: M4 supplies cross-harness routing, but ACP session resume is not implemented in this adaptor. The broader M3 “voice entry point for all sessions” registry is also still separate integration work even though its upstream peer-protocol dependency now has an independent SDK implementation.

Validation and current limits

PR #10617 reports 254 package unit tests and 17 end-to-end tests across eight suites for M4. Four M4 suites run a real spawned qwen --acp child against a fake OpenAI-compatible model endpoint and verify ACP handoff/completion, permission relay including an allowed file write, busy-turn steering reaching a model request, and simultaneous qwen serve plus named ACP backends with correct routing/result return.

PR #10769 reports the M5 test matrix green at 300 unit tests, 17 end-to-end tests, 13 Host-protocol parity tests and 34 script tests. Its reviewer environment records Linux validation for the daemon/wizard path. The PR explicitly does not claim a real macOS Host playback-receipt round trip; the Host application/audio-engine side needs a rebuilt macOS app for that manual verification, and Windows/macOS are not marked as fully tested in the PR matrix.

PR #11369 reports 834 Qwen Live tests passed with 2 manual tests skipped, 258 Host tests passed, 185 built-in-serve Live tests passed, and 17 fake-provider/ACP integration tests across eight files. Repository build/typecheck, CLI bundle, standalone Host build/typecheck, scoped lint/format and lockfile validation also passed in upstream review. Evidence was macOS automated/build/browser-fixture oriented; real DashScope audio/video, native permission prompts, physical Bluetooth coexistence and Windows/Linux were explicitly outside that PR’s validation scope. Release/npm publication was also outside the PR itself, but its code is now included in Qwen Code v0.23.4; that later release does not erase the original platform/manual-test caveats.

PR #11560 separately reports the TypeScript peer SDK’s conformance/public-surface tests and bidirectional manual Linux evidence against a live Qwen Code session. That evidence validates the peer SDK and Qwen cross-session protocol boundary, not Qwen Live M3 integration.

PR #11636 reports 2,956 related unit cases across Qwen Live, SDK, Web Shell, bridge and Session scopes plus two Chromium scenarios, together with build/typecheck/bundle and targeted lint/format/diff checks. Its deterministic browser fixture validates transport/browser projection without live-model variability, but it does not establish real-provider or real-Git end-to-end behavior. Upstream local execution was macOS; Windows and Linux were not locally tested for this change. The result therefore supports the current-main background-execution lifecycle claims above without promoting them into a stable-release or cross-platform blanket claim.

The Qwen Live source package itself remains incubating 0.1.0. Built-in Live retirement is deferred, M3 remains unshipped integration work despite its peer-SDK blocker being cleared, and ACP child-process session resume remains absent.

Relationship to UHP and HarnessRouter

Qwen Live and UHP address different boundaries:

Boundary	Qwen Live	UHP / HarnessRouter
Primary role	Voice/visual control plane over coding-agent sessions	Client ↔ server ↔ selected complete-harness execution contract
Current source backends	Qwen Code through `qwen serve`, plus generic ACP child processes	HarnessRouter exposes eleven released harness backends through UHP
Host transport	Live Host WS protocol v9 in the Qwen Code `v0.23.4` source carrier and current source; M5’s earlier `v0.23.0` carrier used v7	UHP HTTP/SSE contract
Inner agent transport	REST/SSE for Qwen Code; JSON-RPC/stdio for ACP backends	Harness-specific adapter implementation behind the UHP server
Session model	Live-owned voice session plus adaptor-owned coding sessions, proactive monitors and local Memory libraries; current-main Qwen daemon background executions retain separate execution identity	UHP task/session objects at the server boundary
Cross-harness state	Named multi-backend routing ships in Qwen Code `v0.23.0`; the external peer SDK is carried by `v0.23.4` and clears an M3 prerequisite, but Qwen Live M3 integration and ACP adaptor session resume remain pending	Existing HarnessRouter backend catalogue and UHP continuation semantics
Adoption evidence	No native UHP evidence	HarnessRouter integrates Qwen Code; upstream Qwen UHP adoption remains not established

An ACP adaptor inside Qwen Live is an inner composition choice, not evidence that ACP becomes part of UHP or that an ACP-backed child natively adopts UHP. Likewise, Qwen Live’s ability to drive qwen --acp, visual/proactive operation, local Memory, current-main background-execution ownership, or the availability of Qwen’s external peer SDK does not mean HarnessRouter’s UHP→Qwen adapter uses Qwen Live, ACP, or the cross-session peer protocol.

Why it matters

Qwen Live has moved from a single-backend abstraction seam to a concrete multi-backend multimodal control plane. Qwen Code v0.23.0 carries the M4/M5 routing/setup baseline, while stable v0.23.4 carries PR #11369’s stronger Host-delivery contract, selectable visual observation, bounded proactive authority, local Memory and persistent desktop controls.

Post-v0.23.4 PR #11636 adds a different integrity boundary: an automatic background-result execution can no longer be confused with the foreground Live job that owns a receipt. That keeps output, permissions, cancellation, replay, busy state and terminal settlement attached to the execution that actually owns them and prevents a stale/background terminal from falsely completing newer foreground work.

The architectural significance is not merely UI. The design separates user-turn authority, synthetic proactive delivery, backend task lifetimes, background automatic execution, media capture, playback acknowledgement and memory persistence instead of allowing one channel to implicitly authorize or complete another. The v9 output identity/epoch boundary also makes delivery acknowledgement generation-specific rather than accepting an ambiguous playback-complete signal.

PR #11560 removes a different architectural uncertainty: Qwen’s cross-session protocol has an external-program implementation, not only the core implementation from which its documentation was derived. Stable v0.23.4 now carries that implementation and therefore clears the dependency called out by Qwen Live’s M3 roadmap, but it still does not make M3 shipped; qwen-live must integrate the endpoint and its user-owned-session flows before that status changes.

That is meaningful harness-composition evidence. The background-execution change remains unreleased current-main Qwen behavior and the standalone source package remains 0.1.0; it is not a new interoperability standard, a UHP extension, a verified HarnessRouter integration, or native Qwen UHP adoption.

Read UHP and Qwen Code for the released HarnessRouter adapter and upstream Qwen runtime details, harness composition for internal agent/runtime topologies, UHP and ACP for the editor/client↔agent protocol boundary, and HarnessRouter Community Edition for UHP-side multi-backend routing.

Recover configuration and stop the resource you actually own

Start with the current project

Prerequisites and first launch

Choose the background connection

Privacy and troubleshooting

Status first

Architecture

Receipt-style control tools

ACP routing, prompt admission and steering

Post-v0.23.4 current main: automatic background execution is not a foreground job

Guided backend setup

Stable v0.23.4 visual, proactive and Memory boundary

Permission boundary

Result injection and playback confirmation

M3 dependency boundary: external peer SDK now exists

Crash and continuity boundary

Validation and current limits

Relationship to UHP and HarnessRouter

Why it matters

Related pages

Primary sources

Post-`v0.23.4` current main: automatic background execution is not a foreground job

Stable `v0.23.4` visual, proactive and Memory boundary