Shaojin Wen
13e65c1a6e
* feat(web-shell): link GitHub PR/Issue targets in channel events The channel events page showed the repository#number target of GitHub journal events as plain text, so operators had to copy the reference into a browser to inspect the PR or issue behind an event. Chat prompts and the PRs panel already link out; this closes the last unlinked surface. The URL is synthesized in the client from the channel config and the journal fields the GitHub adapter already records, so existing journal history becomes linkable without any daemon or journal change. The origin mapping mirrors the adapter's web origin derivation (github.com, GitHub Enterprise /api/v3, ghe.com data residency), and links pass the same safety and desktop-opener routing as chat links. Non-GitHub channels, removed channels, and malformed references stay plain text. * fix(web-shell): link GitHub events of channels inherited from user settings The events page resolved link metadata from the management listing, which is scope-local: a channel configured in user/system settings with cwd pointing at the project (the setup the GitHub channel guide recommends) has journal rows on the page but no listing entry, so its targets stayed plain text. The journal route now attaches non-secret link metadata (platform type and API base URL only) resolved from the merged settings the workers actually run with, filtered by the same cwd-ownership rule the worker grouping uses so one workspace never sees another's channel metadata. Resolution failure degrades to unlinked rows instead of failing the journal read. The page falls back to this metadata when the listing has no entry, and a source contract test now ties the client origin mapping to the adapter's so the deliberate mirror cannot drift silently. * fix(web-shell): make channel event link metadata safe and authoritative Review of the journal-metadata round found the default settings loader leaking the queried workspace's .env into the daemon's process environment (and able to rewrite a corrupt settings file) on a read-only polling route, and the client preferring the scope-local listing over the merged metadata even though system settings override workspace values. The route now resolves metadata through readSettingsSnapshot on the runtime's effective environment — side-effect-free, corruption throws into the existing degrade path — and the helper requires that view instead of defaulting to loadSettings. The page prefers the journal's merged metadata, keeping the listing as the older-daemon fallback, derives the displayed number from the thread exactly like the URL does, and strips trailing slashes from the base URL on both sides of the origin-mirror contract. The serve protocol doc now documents channelLinkMeta. * fix(cli): resolve channel link metadata against the boot environment snapshot The serve process-env guard flagged the journal route's live process.env fallback: a read-only polling route must not couple to shared mutable process state. Thread the daemon's frozen boot-time environment snapshot through the route deps and use it as the parent-process fallback, the same source the session host resolution already uses, instead of reading the live environment or adding a guard exception. * fix(web-shell): emit the resolved GitHub web origin from the daemon Review round 2 flagged that the web-origin mapping had two owners pinned only by a source-scraping mirror test, and that the boot-environment guard had no test able to fail. Retire the second owner: the channel package now exports resolveGithubWebOrigin as the single mapping owner, the adapter and the journal route both use it, and the route emits the resolved origin as channelLinkMeta.webOrigin so the browser only concatenates. The client's baseUrl derivation remains solely as the older-daemon/listing fallback, and the scraping contract test is replaced by a mapping-owner table (including whitespace-padded env-resolvable values), route origin assertions, and emitted-origin consumption tests. Pin the boot-snapshot guard behaviorally: mount() accepts a daemonEnv override and a new case resolves channels from a boot home that disagrees with the process environment — reverting to a live process.env read now reds that case. Also call the exported resolveChannelOwnerCwd instead of re-implementing the ownership predicate, and correct the protocol doc's read-scope wording for the added settings snapshot.
The open-source AI coding agent for your terminal, editor, desktop, browser, and chat.
中文 | 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, Web UI, SDKs, and chat integrations (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
Open a terminal in your project and start Qwen Code:
cd /path/to/your-project
qwen
Inside the session, run /auth to configure your provider and API key. Then try:
Explain this repository and show me where to start.
See the Authentication Guide and Settings Reference for detailed setup.
See the terminal interface
How to Use Qwen Code
Choose the interface that fits your workflow:
| Interface | Get started |
|---|---|
| Terminal | Run qwen in your project — see Quick Start. |
| Desktop | Download Qwen Code Desktop for macOS, Windows, and Linux. |
| Web | Run qwen serve --open to open the Web UI in your browser. (experimental) |
| Editor | Set up VS Code, Zed, or JetBrains. |
| Chat | Connect Telegram, DingTalk, WeChat, or Feishu, then run qwen channel start. |
For automation and custom integrations:
- Headless — Run
qwen -p "..."in scripts, CI/CD, or batch jobs. - SDKs — Build with TypeScript, Python, or Java.
- Daemon — Run
qwen serveto connect clients over HTTP + SSE (ACP). (experimental) Daemon guide. - Computer Use — Set up native MCP tools or Node REPL + SDK in Qwen Code, Claude Code, or Codex.
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())
Daemon Mode
Run Qwen Code as a long-lived service when you want browser, editor, SDK, and automation clients to share agent sessions without each starting a separate process. The daemon provides the built-in Web Shell and an HTTP + SSE API, supports multiple workspaces, and lets clients reconnect to active sessions.
Start it in the foreground and open the Web Shell:
qwen serve --open
The default address is http://127.0.0.1:4170. To run and manage it in the background instead:
qwen daemon start
qwen daemon status
qwen daemon logs -f
qwen daemon stop
By default, the daemon listens on loopback without bearer authentication; any local process that can reach it can use the full API, including code execution. On shared or untrusted hosts, set QWEN_SERVER_TOKEN and use --require-auth. See the Daemon guide for workspaces, authentication, remote access, and the API.
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) | ✓ | — |
Qwen Code Evaluation
On SWE-bench Verified, seven Qwen Code versions scored 76.40%–77.80% on average using the same Qwen 3.7 Max model (500 tasks, three trials per version).
Full results and evaluation configuration →
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-audio-agent — Realtime full-duplex voice frontend for Qwen Code over ACP — talk hands-free with barge-in and a local wake word
-
🦞 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
Privacy
See the Terms of Service and Privacy Notice, including Chrome extension and Browser Use data handling.
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.