* feat(opentui): add the build, CI and parity tooling for the renderer migration Batch 7 of the ink→OpenTUI migration (#8662): everything the renderer needs to be built, verified and shipped — ink stays the default. Bundled builds silently lose code-block syntax highlighting because @opentui/core resolves its tree-sitter assets package-relatively, which misses inside the esbuild bundle. Relocate the runtime assets (parser worker, grammar wasms/scm, web-tree-sitter, native render library) next to the bundle, and gate OTUI_ASSET_ROOT on the tree being complete for the running platform — @opentui/core throws on any missing key, so an incomplete relocation must fall back instead of half-configuring. Standalone archives gain a Bun runtime (the renderer needs bun:ffi) and per-target @opentui platform packages via the existing release packaging, with --runtime=node restoring classic packaging. The renderer matrix drives interactive E2E under node+ink and bun+opentui, but Batch 6's renderer gate silently falls back to ink on an unsupported runtime, so a green opentui leg could be a false green. QWEN_TUI_RENDERER_STRICT turns that fallback into a loud startup failure for the matrix legs only; user-facing default behavior is unchanged. Parity tooling: a tui-parity workflow with component snapshots and a no-flicker gate (zero full-screen clears, balanced DEC 2026) that runs offline without model credentials, an ink→opentui codemod with a self-test, the PTY/tmux comparison harnesses, and the cli scripts/ tree is now covered by the package typecheck. * fix(ci): build all packages in the tui-parity jobs With prepare skipped, npm ci leaves the CLI's workspace dependencies unbuilt, and a workspace-scoped build of the CLI alone resolves their types from a dist that does not exist yet. The parity jobs must run the repository-root build like the other E2E legs. * fix(build): enforce renderer strict mode and drop musl from standalone packages Address yiliang114's review on the Batch 7 build/CI work: - propagate QWEN_TUI_RENDERER_STRICT into RendererSelection so the dispatcher also fails loudly when the OpenTUI entry returns false or throws, closing the false-green path in the E2E renderer matrix - stage the OpenTUI platform packages only for the bun runtime and drop the -musl variants: the bundled Bun binaries are glibc-linked and cannot start on musl hosts, so the musl render packages claimed support the archives cannot deliver - wipe dist/opentui-assets before re-copying so a stale tree from an earlier bundle cannot satisfy the key-existence runtime gate - route the script-PTY capture branch through spawnScriptPty so the argv form follows the platform, and give it the destroy() that finish() expects from the node-pty-like interface - harden pty-e2e.sh (set -euo pipefail, mktemp+trap, full TCL escaping of the prompt) and tmux-compare.sh (missing-binary check, mktemp+trap) - pin the CI Bun setups to 1.3.14 = DEFAULT_BUN_VERSION so an upstream Bun release cannot flip the gating legs on its own * fix(build): keep classic Node packaging as the standalone default The temporary OpenTUI preview flavor (--runtime=bun) stays available but no longer replaces the default release archives, keeping Batch 7 additive for existing standalone users. * fix(scripts): compare prettier-normalized output in the codemod self-test Address F1 and F3 from the deep verification report: - The self-test compared the codemod's raw output against the prettier-formatted fixtures/after.tsx, so 2 of 17 tests failed as committed. Normalize both sides through the repo prettier config before comparing (tests 1 and 6); the harness awaits because prettier 3's format() is async-only. - Refresh the tui-parity.yml baseline entry from 2190 to the measured 2508 bytes so the ratchet tracks real growth. * fix(build): gate standalone opentui assets by runtime flavor Node archives carry no opentui-assets tree at all: the renderer needs bun:ffi, and cross-built archives would only hold another platform's native library that the all-or-nothing asset gate could never activate. Bun archives now prune every @opentui/core-* directory that does not belong to the build target, dropping the build host's library from the archive. The npm-package allowlist comment is corrected to match the observed fallback behavior. * test(cli): cover the OpenTUI strict-mode dispatch and e2e renderer matrix main() now has coverage for the four dispatch outcomes: strict mode throws both when the OpenTUI entry declines to start and when it boots with an error, and non-strict mode falls through to startInteractiveUI. resolveE2eCliCommand gains coverage for the opentui leg — bun on PATH resolves to bun, and a missing bun fails with the actionable error.
The open-source AI coding agent that lives in your terminal.
中文 | Deutsch | français | 日本語 | Русский | Português (Brasil) | 한국어
Why Qwen Code?
- Agentic out of the box — Auto-Memory, Auto-Skills, SubAgents, Agent Teams, and MCP. Dynamic workflows, zero setup.
- Open-source, inside and out — The framework and the Qwen models are open-source. They evolve together. No vendor lock-in.
- Multi-protocol — Supports OpenAI, Anthropic, Gemini, and Qwen APIs. Any third-party provider or local model (Ollama / vLLM). Switch at runtime.
- Beyond the terminal — IDE plugins, Desktop app, daemon mode, SDKs, and IM bots (Telegram / DingTalk / WeChat / Feishu).
Tip
Qwen Code is actively iterating on itself — using its own agent and models to file issues, submit PRs, review code, and run tests. Powered by the community, driven by AI.
Installation
Linux / macOS:
curl -fsSL https://qwen-code-assets.oss-cn-hangzhou.aliyuncs.com/installation/install-qwen-standalone.sh | bash
Windows:
irm https://qwen-code-assets.oss-cn-hangzhou.aliyuncs.com/installation/install-qwen-standalone.ps1 | iex
Restart your terminal after installation to ensure environment variables take effect.
NPM / Homebrew
NPM (requires Node.js 22+):
npm install -g @qwen-code/qwen-code@latest
Homebrew (macOS / Linux):
brew install qwen-code
Quick Start
qwen # Launch interactive terminal UI
# Inside the session:
/auth # Configure your provider and API key
See the Authentication Guide and Settings Reference for detailed setup.
How to Use Qwen Code
| Mode | Command | Use Case |
|---|---|---|
| Interactive | qwen |
Terminal UI with rich rendering, @file references, slash commands |
| Headless | qwen -p "..." |
Scripts, CI/CD, batch processing — no UI |
| IDE | — | VS Code, Zed, JetBrains |
| Desktop | — | Qwen Code Desktop — GUI for macOS, Windows, Linux |
| Daemon | qwen serve |
Shared agent session over HTTP+SSE (ACP). Multiple clients, one agent. (experimental) Docs |
| SDK | — | TypeScript, Python, Java |
| IM Bot | qwen channel |
Connect to Telegram, DingTalk, WeChat, or Feishu |
SDK example (Python)
import asyncio
from qwen_code_sdk import is_sdk_result_message, query
async def main() -> None:
result = query(
"Summarize the repository layout.",
{
"cwd": "/path/to/project",
"path_to_qwen_executable": "qwen",
},
)
async for message in result:
if is_sdk_result_message(message):
print(message["result"])
asyncio.run(main())
Capabilities
If you know Claude Code, you already know Qwen Code — and then some. We've put significant effort into bringing Qwen Code to feature parity with Claude Code, improving both breadth and reliability across the board.
| Feature | Qwen Code | Claude Code |
|---|---|---|
| SubAgents, Agent Teams, Dynamic Workflows | ✓ | ✓ |
| Auto-Memory, Auto-Skills, Hooks | ✓ | ✓ |
| Built-in Skills (/review, /batch, /loop, /bugfix…) | ✓ | ✓ |
| MCP, Plan Mode, LSP Integration | ✓ | ✓ |
| Auto Mode, Sandbox, Git Worktrees | ✓ | ✓ |
| Computer Use (desktop automation) | ✓ | ✓ |
| IDE Plugins (VS Code / JetBrains / Zed) | ✓ | ✓ |
| SDK | ✓ | ✓ |
| Headless Mode, Session Management | ✓ | ✓ |
| Open-source — model and framework | ✓ | — |
| Multi-protocol (OpenAI / Anthropic / Gemini / Qwen + any provider) | ✓ | — |
| Agent Arena (multi-model head-to-head on same task) | ✓ | — |
Daemon Mode — qwen serve (multi-client shared agent) |
✓ | — |
| IM Channels (Telegram / DingTalk / WeChat / Feishu) | ✓ | — |
Ecosystem
-
Qwen Code Desktop — Official desktop app for macOS, Windows, and Linux
-
AionUi — A modern GUI for command-line AI tools including Qwen Code
-
Gemini CLI Desktop — A cross-platform desktop/web/mobile UI for Qwen Code
-
🦞 Qwen Code Claw — Let other agents (Claude, Codex, etc.) delegate coding tasks to Qwen Code via ACP. Paste this prompt into your agent:
Use Qwen Code as a coding agent. First, fetch and read this skill reference:
https://raw.githubusercontent.com/QwenLM/qwen-code/refs/heads/main/.qwen/skills/qwen-code-claw/SKILL.md
Then follow the instructions inside to install, authenticate, and use Qwen Code via acpx for all coding tasks.
- Aliyun Model Studio CLI — Official CLI for Aliyun's AI platform (
bailian-cli). Extends Qwen Code with image/video generation, knowledge retrieval, app orchestration, and model deployment
Contributing
Contributions are welcome! See CONTRIBUTING.md for guidelines.
Acknowledgments
This project was originally based on Google Gemini CLI v0.8.2. We gratefully acknowledge the Gemini CLI team's excellent work. Starting from Qwen Code v0.1, we stopped syncing with upstream and began independent development as a multi-protocol, multi-platform agent framework with deep integrations for Qwen models and beyond.
