mirror of
https://github.com/QwenLM/qwen-code.git
synced 2026-11-07 06:19:43 -10:00
ChiGaoand秦奇
d96f264de7
* feat(telemetry): link daemon HTTP request spans to inbound W3C traceparent
The daemon HTTP surface records a request span per request, but every span
starts a new trace: a caller forwarding the standard W3C traceparent header
(OTel-instrumented clients, proxies, gateways) gets no linkage back to its
own trace.
Extract traceparent/tracestate from inbound request headers in the daemon
telemetry middleware and parent the request span to that remote context.
Extraction reuses the same path as the existing JSON-RPC _meta extraction
(global propagator first, strict manual fallback so behavior is identical
without a registered SDK) and fails closed: requests without a valid header
keep the exact current span shape.
* fix(telemetry): guard inbound traceparent sampling and align W3C fallback
- Force TraceFlags.SAMPLED on inbound HTTP parents via the existing
shouldForceSampled() matrix: an unsampled remote parent under the
default parentbased_always_on sampler silently dropped the request
span, the whole next() subtree, and the session-subprocess spans
forwarded via _meta (review C1).
- Replace the hand-rolled manual fallback parser with a direct
W3CTraceContextPropagator instance so acceptance rules (future
versions, tracestate, all-zero ids, version-00 extension field)
match the registered path with or without an initialized SDK.
- Gate middleware extraction behind isTelemetrySdkInitialized() to
skip the hot-path parse when telemetry is off, and emit a debug
daemon log when a present-but-invalid traceparent header is
rejected.
- Re-export DaemonRequestSpanOptions from the core barrel and add a
type-level guard so the parentContext field cannot silently
disappear (vitest alone cannot catch its removal).
* chore(vscode): regenerate companion NOTICES.txt for @opentelemetry/core
* fix(telemetry): lazy-load OTel core fallback propagator behind SDK init
Address review feedback on the inbound traceparent linkage:
- Keep @opentelemetry/core out of the static graph. The module-level
W3CTraceContextPropagator in daemon-tracing.ts pulled the CJS barrel
(bot-measured +65,046 bytes) into every closure loading that module,
including telemetry-off deployments. daemon-tracing.ts now keeps only a
holder + setter (setDaemonFallbackPropagator, typed against
@opentelemetry/api — type imports stay free at runtime); the lazy
sdk-impl.ts chunk, whose closure already contains @opentelemetry/core via
sdk-node/resources, constructs and injects the W3C instance on the
successful SDK assembly path. Until injection, extraction returns no
parent context: the HTTP edge is already gated on
isTelemetrySdkInitialized (nothing changes when telemetry is off), and
the _meta edge's consumers (withDaemonSpan / withInteractionSpan)
short-circuit on the same flag, so an unresolved pre-init parent never
had an observable effect.
- Add the mutation-verified fail-closed test for the header-extraction
try/catch in daemonTelemetryMiddleware: a throwing extractor leaves the
request settling normally (recordDaemonHttpRequest still fires once)
with no parentContext on the span options.
- Record the rejected traceparent value (truncated to 128 chars) as
http.request.header.traceparent on the invalid-header breadcrumb —
traceparent only carries trace-id/span-id/flags, so this is
privacy-safe and makes broken cross-service joins diagnosable.
Also document why the _meta extraction path deliberately skips
shouldForceSampled (trusted in-process bridge vs external HTTP input).
* feat(telemetry): carry inbound trace id into daemon access log with telemetry off
Telemetry off (the default) left daemon logs without any trace id: with no
request span, the log trace prefix never fires, so a caller forwarding W3C
traceparent could not be joined to its daemon log lines.
The middleware now parses the header with a plain regex
(extractInboundTraceId — same shape/all-zero/ff rejections as the W3C
propagator, no OTel machinery) and stores the trace id on the per-response
telemetry context. The access log emits it as the camelCase traceId field
of "request completed", keeping the log-based join alive with no telemetry
config and no trace backend. With telemetry on nothing changes: the request
span already carries the caller's trace id into the log prefix.
* fix(telemetry): unify _meta/HTTP sampling and repair build export
- Export extractInboundTraceId from the core barrel: the previous commit
exported it from daemon-tracing.ts only, so downstream package builds
failed with TS2305.
- extractDaemonTraceContext now applies the same shouldForceSampled()
matrix as the HTTP edge: the _meta path is also reachable from direct
ACP clients (acpAgent newSession/loadSession/unstable_resumeSession
and Session.prompt pass caller-controlled _meta), so an external
sampled=0 parent no longer silences daemon spans there either. The
in-process bridge is unaffected (its injected values are already
SAMPLED).
- The rejected-header breadcrumb now goes through sanitizeLogText so a
crafted traceparent cannot forge log line structure with control
characters.
- Add the sdk-impl wiring test: after initializeTelemetry the injected
W3C fallback propagator resolves inbound HTTP parents.
* fix(telemetry): align log-path traceparent parsing and emit traceId in both modes
- extractInboundTraceId now mirrors the vendored W3C propagator's
acceptance exactly: single optional leading/trailing whitespace and
trailing extension fields above version 00 (version 00 must stay
four fields). Previously the strict four-field anchor made the two
paths disagree on the same forward-compatible header, silently
dropping the access-log traceId for exactly the callers the
propagator path supports.
- The camelCase traceId access-log field is now captured whenever a
valid header parses, regardless of telemetry mode, so one saved log
query / alert shape works for every deployment; with telemetry on the
snake_case span prefix carries the same id redundantly.
* fix(telemetry): move inbound trace id getter out of the middleware module
52d572c0f2 made the access log statically import the telemetry
middleware module to read the captured inbound trace id. The access log
sits inside the serve fast-path pre-listen closure (run-qwen-serve
imports it directly), so the middleware's core-barrel import graph came
along for the ride and check-serve-fast-path-bundle started failing:
the 5.6MB core chunk (shell tool, glob, chokidar, @iarna/toml, fzf)
became statically reachable from run-qwen-serve.
Move the response-context symbol, its type, and the
getDaemonTelemetryInboundTraceId getter into a new import-light
telemetry-context.ts; the middleware imports the symbol from there and
re-exports the getter, so the access log no longer links against the
telemetry module at all.
* fix(telemetry): capture inbound trace id pre-auth under a dedicated symbol
* test(telemetry): pin the trace id seam through the context module getter
---------
Co-authored-by: 秦奇 <[email protected]>
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.