feat(byoa): run agents on Qwen Code

[WhichPaths]

Finishes the list in #75. qwen was already in ENGINE_LABEL / ENGINE_BIN and ENGINE_VERSION_SPECS, so the Computers tab could report its version — and Cumora still could not wake it.

The one thing worth knowing about this fork

Qwen Code is a Gemini CLI fork and shares its flags — -o stream-json, -p, -r, -m. It does not share Gemini's output. Real bytes from @qwen-code/qwen-code@0.22.3:

{"type":"result","subtype":"error_during_execution","uuid":"…","session_id":"…","is_error":true,"duration_ms":0,"num_turns":0,"usage":{"input_tokens":0,"output_tokens":0},"permission_denials":[],"error":{"message":"No auth type is selected…"}}

That is Claude Code's envelope, not Gemini's {type,timestamp,status,stats}. An adapter derived from #99 would have parsed nothing at all.

It is also why this adapter is thin. spawnEngine already sniffs exactly that shape, so the wake path needs no parser of its own and gets the session id, the terminating usage, the real model, and one ledger hop per assistant message for free.

What did need new code

Triage. -o json is not Claude's {result,usage} object here — it is the same stream events wrapped in a JSON array — so there is no envelope to unwrap and the reply has to be assembled from the assistant text blocks. qwenReplyFromStream() does that and is exported and unit-tested directly (pure, and the one part a fake binary can't exercise through spawnEngine).

Triage runs --safe-mode, which is qwen's own switch for "ignore every customization": context files, hooks, extensions, skills and MCP servers stay unloaded — the same thing --strict-mcp-config buys the Claude triage path, and it keeps a cold triage spawn cheap. Checked in the shipped bundle that it gates only tools/permissions/context/hooks and not security.auth, so it cannot break an operator's credentials, and that --yolo (an argv flag) still wins over it, so nothing stalls on an approval nobody is there to give.

Correcting myself from #99

I said in #99 that qwen accepts -y without documenting it, and that building unattended behaviour on that would be unsafe. Half right: 0.22.3's help really has no -y entry — it was dropped in the subcommand restructure — but the flag is not merely accepted. From the shipped bundle:

function getHeadlessYoloSafetyWarning(config, env) {
  if (config.getApprovalMode() !== "yolo") return null
  …
}

The headless yolo warning fires only when approval mode is actually yolo, and running qwen -o stream-json -y prints it. So -y genuinely takes effect; it is a working flag with a help regression, not undocumented behaviour. That was worth checking rather than leaving as a hunch.

Shape

Run	qwen --output-format stream-json --yolo [--resume <id>] [--model X], prompt on stdin
Persistent session	none — 0.22.3 has no stream-json input mode
Continuity	--resume <id>. Deliberately not -c/--continue: that resumes the newest session for the project, and one machine runs many agents out of many homes
Persona	QWEN.md + .qwen/skills/
Triage	--safe-mode --yolo [--model $CUMORA_TRIAGE_MODEL]
Override	CUMORA_QWEN_ARGS, which keeps --resume and the stdin prompt

The big-brain doctor probe passes no --model at all. Qwen Code is multi-provider (its own OAuth, DashScope, any OpenAI-compatible base URL), so there is no cheap model id that is right for everyone — pinning one would report on a model the operator's wakes never use. A test caught me getting this wrong the first time: my ask() always appended --model, so the big probe was silently running on the cheap triage model.

One thing that would have failed silently

byoa-qwen goes into the shared BYOA_SOURCES whitelist. normalizeByoaSource() falls back to 'byoa-claude' for anything unknown, so omitting it would not have errored — it would have attributed every qwen run's spend to Claude in the ledger.

Drive-by

cli-version.ts told the next person to keep the catalog in sync with electron/main.cjs LOCAL_CLIS, which no longer exists — the catalog moved into that file itself. Misdirecting the list of things-to-update is how one of two copies gets fixed and the other doesn't, which is precisely what caused #102. One comment, corrected to the lists that do exist.

Checks

16 tests in agents-computer-engine-qwen.test.ts driving a fake qwen on PATH that replays the captured envelope: turn parsing with no adapter-side parser, per-assistant-message hops, resume-by-id (and not --continue), the no-auth failure, text assembly, tool_use blocks contributing no text, a failed result with text already streamed, banner noise and truncated lines, --safe-mode triage, CUMORA_TRIAGE_MODEL reaching both triage and the small probe, the big probe leaving the model alone, seedHome layout, the args override, and detection.

76/76 across the engine and guard test files locally; typecheck, biome lint ., and both guards clean.

[yetone]

Thanks for this — the adapter work and the 314-line test file are solid, and all six checks were green when you pushed. I can't merge it as-is: it now conflicts with main in four files (registry.ts, router.ts, src/api/client.ts, src/lib/engines.ts). Please rebase.

The good news is that a rebase should make this PR noticeably smaller, because two things landed since you opened it that were built for exactly this problem.

#116 collapsed the engine lists to one declaration. src/lib/engines.ts now derives the ordered UI list, the RunnableEngineId type, and the membership set from a single RUNNABLE_ENGINES array — and qwen is already present in ENGINE_LABEL and ENGINE_BIN as a detect-only entry. So most of your +1/-1 client-side edits collapse into adding 'qwen' to that one array; several of the files you touched no longer need touching at all.

#114 added a CI guard that will tell you if you miss one. scripts/guard-engine-registry.mjs (+ server/src/__tests__/guard-engine-registry.test.ts) walks every list an engine has to appear in and fails naming the ones that are incomplete. Its header comment names the failure mode this PR was most at risk of:

Missing one does not error — BYOA_SOURCES in particular is read through normalizeByoaSource(), which maps anything unknown to 'byoa-claude', so a half-wired engine silently bills its runs to Claude.

You already touched byoa-source.ts and llm-ledger.ts, so you were tracking that — but after the rebase the guard proves it instead of you and I having to check by eye. Run node --import tsx --test server/src/__tests__/guard-engine-registry.test.ts locally and it will enumerate anything still missing.

One note on server/src/agents/computer/cli-version.ts: ENGINE_VERSION_SPECS already carries a qwen entry (@qwen-code/qwen-code), and #117 has since reworked the spawn path in that file for Windows shims — so re-check your +3/-1 there against the new version rather than replaying it.

Rebase onto main, let the guard run, and ping me — happy to take another look.