mirror of
https://github.com/QwenLM/qwen-code.git
synced 2026-08-07 07:45:54 +00:00
ec4f1e02e4
* fix(cli): probe sandbox runtime before selecting it Sandbox selection treated PATH presence as proof a runtime works, so an installed-but-unusable docker (daemon stopped, socket unreachable, user not in the docker group) was still selected and the podman branch below it became unreachable. Each candidate is now probed with `version` — the cheapest command that still contacts the daemon — and the first one that actually runs wins. When nothing usable is found, the error names the runtime that broke and quotes its failure instead of claiming nothing is installed. An explicit QWEN_SANDBOX choice is never silently redirected; it fails with the daemon error attached. sandbox-exec is not probed, being a kernel facility rather than a daemon client. Fixes #7732 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(cli): attribute the sandbox command to its real source The probe failure hardcoded "(from QWEN_SANDBOX)", but an explicitly named command also arrives from --sandbox or tools.sandbox in settings. Naming the env var unconditionally sends a user who never set it looking in the wrong place — the same misdirection this change set out to remove. The parenthetical is now emitted only when the env var actually supplied the value, which also corrects the pre-existing "Missing sandbox command" message. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(cli): apply source-accurate attribution to the auto-detect errors too The explicit-string path stopped hardcoding QWEN_SANDBOX, but the auto-detect errors still did, so `qwen --sandbox` with a broken runtime pointed at an env var the user never set. Both auto-detect messages now name the env var only when it was what enabled sandboxing, and otherwise suggest --sandbox. Also lowers the probe timeout from 10s to 5s. Probes run sequentially, so the ceiling is paid once per wedged runtime; a healthy `docker version` answers in roughly 200-500ms, so 5s keeps an order of magnitude of headroom while halving the worst-case startup delay. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * test(cli): assert the sandbox probe argv and timeout The spawnSync stub routed on command name alone, so the probe arguments were never observed. Rewriting the probe to `docker --version` — which prints the client build without contacting the daemon, restoring the original defect — left all 12 tests green, as did deleting the timeout that bounds a wedged daemon. Validate both in the stub, so every probing test carries the check, and pin the argv at the fallback call site where the behavior is asserted. Reported by @wenshao in the mutation matrix on #7734 (M9, M8). * test(cli): cover the empty-output and timeout probe branches Two probe branches in probeSandboxCommand were unpinned, so a mutant in either survived the whole suite: - a non-zero exit with empty output relied on the synthesized-message fallback; dropping it made the probe return undefined and a broken runtime read as usable - the result.error branch that the probe timeout produces had no test; deleting it degraded the error text with the suite still green Each new test fails against its mutant and passes on the real code. Reported by @qwen-code /review on #7734. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * test(cli): isolate the sandbox probe in config precedence tests The image-precedence tests enable the sandbox and assert only which image wins. Since the runtime probe added here spawns a real `docker version` subprocess, and this file mocks command-exists but not child_process, the probe runs for real. On macOS the sandbox-exec branch returns before probing, so it passed there and on CI runners that have docker; on any other host without a running daemon getSandboxCommand throws and all four tests fail on image assertions they never reach. Mock the docker/podman `version` probe to report healthy, so selection is deterministic and the tests exercise image precedence on every platform. Every other spawnSync call stays real. Reported by @qwen-code /review on #7734. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(cli): cache the sandbox probe and sanitize its error output loadSandboxConfig runs twice on a sandboxed startup, so every candidate was probed twice — the wedged-docker-then-podman fallback paid the 5s cap twice (~10s), which the PR description wrongly called "once per wedged runtime". Cache each command's probe outcome per process (with a test-only reset), mirroring the ripgrep health cache, so a runtime is contacted at most once. The probe also returned the runtime's stderr verbatim into FatalSandboxError messages, carrying ANSI/control bytes to the terminal. Strip them with the existing stripAnsiAndControl helper, whose own doc names this case. Both requested by @wenshao in the review on #7734 (items 1 and 3). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(cli): keep an all-control-character probe failure from reading as usable The sanitizer checked the failure line for emptiness before stripping, so a runtime whose stderr is only escape/control bytes stripped to '' — falsy — and the broken runtime was selected as usable, reintroducing the presence-vs- liveness bug through the sanitizer. Check emptiness after stripping and fall back to the synthesized message. Also drop the redundant `candidate !== 'sandbox-exec'` guard (sandbox-exec is only a candidate once its presence is confirmed), reword the all-broken hint to "try another installed runtime" since another may be installed but also broken, and add tests pinning the control-character failure and the first-of-several- broken diagnosis. Reported by @qwen-code /review on #7734. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| .github | ||
| .husky | ||
| .qwen | ||
| .vscode | ||
| docs | ||
| docs-site | ||
| eslint-rules | ||
| integration-tests | ||
| integrations/external-context | ||
| packages | ||
| patches | ||
| scripts | ||
| .dockerignore | ||
| .editorconfig | ||
| .gitattributes | ||
| .gitignore | ||
| .npmrc | ||
| .nvmrc | ||
| .prettierignore | ||
| .prettierrc.json | ||
| .yamllint.yml | ||
| AGENTS.md | ||
| CHANGELOG.md | ||
| CLAUDE.md | ||
| CONTRIBUTING.md | ||
| Dockerfile | ||
| esbuild.config.js | ||
| eslint.config.js | ||
| eslint.legacy-filenames.mjs | ||
| LICENSE | ||
| Makefile | ||
| package-lock.json | ||
| package.json | ||
| README.md | ||
| SECURITY.md | ||
| tsconfig.json | ||
| vitest.config.ts | ||
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.
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.