易良andQwen-Coder
35aa4b76ae
* fix(core): require explicit trust for settings-file project hooks A repository .qwen/settings.json SessionStart hook ran at startup with no trust prompt while the folder-trust feature was off by default: getProjectHooks() consulted isTrustedFolder(), which returns trusted when the feature is disabled. Gate it on isExplicitlyTrustedFolder() instead, matching the frontmatter-hook and LSP gates from #16182. Update the hooks docs, and grant explicit trust in hook test fixtures. Refs #14746 Co-authored-by: Qwen-Coder <[email protected]> * style(core): use Array<T> for the tuple-array cast Co-authored-by: Qwen-Coder <[email protected]> * test(integration): grant explicit trust in ACP parity fixtures The ACP parity rig spawns the CLI with its own QWEN_HOME, so the trust granted by TestRig.setup() never reaches those sessions. With project hooks now requiring explicit folder trust, the UserPromptSubmit hook scenarios silently lost their hooks. Seed the scenario home with folder trust enabled and the rig directory trusted, matching the tool-hook suites. Co-authored-by: Qwen-Coder <[email protected]> * fix(core): align project-hook trust with the interactive boundary Follow the Claude Code model: interactive sessions keep the explicit folder-trust gate, while non-interactive invocations (-p, piped stdin, ACP/SDK embeddings) treat trust as implicit — the caller chose the directory and there is no prompt surface. This keeps platform embedders working without trust-file migration. Surface a startup warning when interactive project hooks are withheld so the gate is not silent, and document the headless contract. Revert the integration-fixture trust grants that the headless exemption makes unnecessary. Refs #14746 Co-authored-by: Qwen-Coder <[email protected]> * test(integration): drop ACP parity trust seeding made moot by headless exemption The parity rig spawns non-interactive ACP sessions, which now treat trust as implicit, so the seeded trustedFolders.json only perturbed the request-snapshot comparison (an extra tmp/ tree under .qwen-home). Restore the fixture to its main-branch shape; all 23 parity cases pass. Co-authored-by: Qwen-Coder <[email protected]> * fix(cli): tolerate partial settings shapes in the project-hook warning The startup warning read settings.workspace.settings.hooks without optional chaining; AppContainer tests render with a partial LoadedSettings mock, and a missing workspace scope crashed the effect before config initialization completed. Guard the lookup; all 272 AppContainer tests pass. Co-authored-by: Qwen-Coder <[email protected]> * docs(hooks): resolve trust-gate wording contradictions (R1-5) Troubleshooting step 3 still stated the legacy trusted-folder rule and the restart list omitted security.folderTrust and persisted trust decisions. Align both with the interactive explicit-trust gate and the headless implicit-trust contract, and mention the withheld-hooks startup warning and browser state. Co-authored-by: Qwen-Coder <[email protected]> * test(integration): drop dead ACP trust seeding in the tool-hook suites The per-session trustedFolders.json written beside the QWEN_HOME override is never read: getTrustedFoldersPath() prefers the inherited QWEN_CODE_TRUSTED_FOLDERS_PATH that TestRig.setup() stubs. Both blocks sit in front of an --acp spawn, and ACP sessions are non-interactive, so the headless exemption already loads project hooks without any trust grant. Remove the writes and the now-unused realpathSync import, restoring both suites to their base shape. Refs #14746 * test(cli): pin the folderTrust derivation behind the project-hook gate The interactive gate is covered by the Config table, but nothing pinned settings.security.folderTrust.enabled -> Config.folderTrust. Assert that loadCliConfig derives it and defaults it to false, so a derivation flipping to true cannot silently arm repo-supplied hooks. Verified the case goes red when the default is mutated to true. Refs #14746 * docs(hooks): align trust-boundary descriptions with implementation Remove the unimplemented claim that withheld project hooks appear in the hook browser. Clarify that loop.md retains the legacy folder-trust predicate while executable project hooks use explicit interactive trust. Co-authored-by: Qwen-Coder <[email protected]> * fix(cli): keep folder trust out of workspace reach The project-hook gate reads security.folderTrust.enabled from merged settings, so a repository could enable the very flag that authorizes its own hooks and then reach any pre-existing TRUST_FOLDER or TRUST_PARENT rule for the directory. Restrict the key to the operator scopes, beside allowPrivateNetworkHooks, and pin both directions: a workspace can neither enable the gate nor disarm a user's setting. Also close the smaller review notes. The startup warning no longer blames trust when disableAllHooks removed the hook system entirely, and it now has coverage for the warned and both silent branches. Every hook fixture ran pre-trusted, so add an interactive integration case that declines trust and asserts the hooks never fire, the warning names the remedy, and the tool result still reaches the model unmarked. Drop the duplicated node:fs import and correct the docs claim that IDE trust decisions apply live to settings-file hooks. Refs #14746 Co-authored-by: Qwen-Coder <[email protected]> * test(cli): align the daemon trust-grant case with the workspace restriction security.folderTrust is now stripped from workspace scope, so a grant on a workspace that only self-enables trust reports the disabled state instead of refusing an ineffective grant. Keep the alias DO_NOT_TRUST fixture: if the restriction regresses, the grant throws again and this case goes red (mutation-verified). Fixes the Test (ubuntu-latest) failure ona89935fa. * test(cli): follow operator trust in the ancestor-trust case R1-22 asserted that a workspace folderTrust value reaches the merged settings, which is the behavior the workspace restriction removes. Drive the case from the operator's flag instead: the merged value must survive the repo's opposing declaration, and the ancestor provider must follow the operator — denying every ancestor on the target's DO_NOT_TRUST rule when the feature is on, falling back to directory safety when it is off. Mutation-verified: dropping the restriction turns both cases red. Fixes the Test (ubuntu-latest) failure on6851f531. Co-authored-by: Qwen-Coder <[email protected]> --------- Co-authored-by: Qwen-Coder <[email protected]>
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.