Qwen Code

Getting oriented in an unfamiliar repository

Commit or stash local work, run qwen in the project root and connect a provider with /auth. Start in Plan mode with /plan so the first exploration is read-only, ask for the structure and entry points, then switch to Ask Permissions for the first change. Record build and test commands in QWEN.md so later sessions start with the same context. Check every diff before accepting it, and run /doctor when the provider or settings look wrong.

Choosing a model provider or a local model

Decide first where code context may go. A Qwen Plus or Pro subscription suits individual interactive use, while CI and unattended containers need an API-key route because the subscription sign-in is a browser flow. For QwenCloud, pick China or International explicitly, since that choice sets the endpoint. To keep prompts on your own hardware, point an openai provider at a local Ollama, vLLM or LM Studio base URL as described in the model providers reference, and test tool calling and image input with the exact model before rolling it out.

Running Qwen Code in CI and scripts

Use qwen -p with --output-format json and parse the final result with a tool such as jq, or stream-json for event-level progress. Store the API key as a CI secret, pin the CLI version, and set --max-session-turns, --max-wall-time or --max-tool-calls so a failing task stops with a known exit code. Avoid YOLO on shared runners unless the job runs in an isolated container, and keep .qwen/ out of version control as the GitHub Action guide recommends.

Reviewing pull requests

Run /review 123 for a pull request or plain /review for uncommitted changes. Use --effort low for a quick unverified pass and the default high effort for pull requests that matter, keeping in mind that high effort fans out into many model calls and runs build and test commands. Add --comment only after checking the findings locally. For repository-wide automation, the GitHub Action reacts to @qwencoder /review comments, and its output should be treated as review input confirmed by tests.

Confining commands on Linux workstations

Install Bubblewrap at /usr/bin/bwrap, then set tools.executionSandbox in user or system settings with filesystem set to workspace-write and network set to closed. Workspace settings cannot change this policy. Run qwen sandbox --verify, confirm that a write outside the workspace fails, and then run an ordinary task. Note that reads remain broad, MCP, hooks and worktree management are disabled in this mode, and the daemon and ACP clients reject it.

Sharing one agent through the daemon and Web Shell

Start qwen serve when browser, editor, SDK and chat clients should share sessions without each spawning a process. On a single-user laptop the loopback default is convenient, but any local process can then run code as the daemon user, so set a stable QWEN_SERVER_TOKEN and --require-auth on shared machines. For phone or LAN access, bind with --hostname, serve HTTPS with a locally trusted certificate and allow the browser origin, following the daemon guide.