E2E Testing Guide

How to run the Qwen Code CLI end-to-end, from building the bundle to inspecting raw API traffic. Use when unit tests aren't enough and you need to verify behavior through the full pipeline (model API → tool validation → tool execution).

Setup

Which binary to use

• Reproducing bugs: use the globally installed qwen command, this matches what the user ran when they filed the issue.
• Verifying fixes: build first (npm run build && npm run bundle), then run node dist/cli.js, this tests your local changes.
• Runtime-only checks (fastest): npm run dev -- "<prompt>" <flags>, runs TS source via tsx, no build. Use build && bundle + node dist/cli.js only when the shipped artifact itself matters. (<qwen> below can be npm run dev --.)

Running against a real model

Headless auth comes from ~/.qwen. Force a known-good model with --auth-type + --model:

<qwen> "your prompt" --auth-type openai --model deepseek-v4-flash \
  --approval-mode yolo --output-format json

Gotcha: --model alone won't switch providers, --auth-type (openai/anthropic/qwen-oauth/gemini/vertex-ai) does. Omit it and the run falls back to the default provider and dies on its missing key.

Isolating runtime artifacts

QWEN_RUNTIME_DIR=<dir> redirects qwen's runtime output, tmp/, debug/, and projects/<sanitized-cwd>/... (chat recordings, auto-memory, history), into <dir> instead of ~/.qwen. Config (settings.json, OAuth tokens, commands/) still reads from ~/.qwen, so real auth and provider config work without any setup.

Use when repeated test runs would clutter your real chat history or auto-memory. Skip when the bug you're reproducing depends on the user's actual history or runtime state, that is the repro.

QWEN_RUNTIME_DIR=/tmp/test-1/runtime <qwen> "prompt" ...

Run modes

Headless Mode