Qwen Code: the curl pipe, the Node 22 floor, and the experimental serve mode

The installer pipes a remote script straight into bash

Two of the documented install paths never put a file on your disk that you can read first. On Linux and macOS the command is a curl pipe into bash, and on Windows it is irm piped into iex:

curl -fsSL https://qwen-code-assets.oss-cn-hangzhou.aliyuncs.com/installation/install-qwen-standalone.sh | bash

irm https://qwen-code-assets.oss-cn-hangzhou.aliyuncs.com/installation/install-qwen-standalone.ps1 | iex

Both fetch from an Aliyun OSS bucket in Hangzhou and execute whatever that URL returns at the moment you run them, so a rerun a week later can run different bytes than the first time. If you want to see the script before it runs, save it locally, read it, then run it yourself. The two paths that do not pipe anything are Homebrew and npm: `brew install qwen-code` on macOS and Linux, and `npm install -g @qwen-code/qwen-code@latest`, which the docs place behind Node.js 22 or newer. Whichever route you take, the install note tells you to restart your terminal so environment variables take effect.

Node 22 is the floor and pnpm is the pinned package manager

package.json declares engines.node as >=22.0.0, sets the module type to module, and pins packageManager to [email protected]. The README states the npm install requires Node.js 22+, and anyone building from source needs pnpm at the pinned version rather than a bare npm. The Makefile hides the package manager behind npm scripts: install runs npm install, build runs npm run build, and run-npx is `npx https://github.com/QwenLM/qwen-code`, which exercises the published package straight from the GitHub URL. Consequence for readers stuck on an older runtime: the README attaches the Node.js 22+ requirement only to the npm path, not to the standalone installers or Homebrew.

/auth is the first command, and it picks which protocol answers you

Installation never asks for a key. You start the CLI yourself in a project directory, then configure the provider from inside the session:

cd /path/to/your-project
qwen

Explain this repository and show me where to start.

Running `/auth` inside that session is what sets the provider and the API key, and that single choice routes every later turn. The agent speaks OpenAI, Anthropic, Gemini and Qwen APIs, and the README adds that any third party provider or a local model behind Ollama or vLLM works as well, switchable at runtime. Consequence: the token bill, the rate limits and the handling of your source code belong to whichever provider you name in `/auth`, not to Qwen Code. The Apache-2.0 grant covers the agent and says nothing about what your provider does with the prompts it receives.

qwen -p strips the interactive loop out, which is the point and the risk

The same binary has a headless form for automation, and the SDKs wrap it in three languages: TypeScript, Python and Java. The Python shape passes the prompt plus a dict holding the working directory and the executable to invoke, then streams results back and lets you filter for the final message:

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())

Consequence: headless means unattended. There is no session to type into, no slash command palette, and nothing that pauses for a human decision. If you point `qwen -p "..."` at a CI job or a batch script, every guardrail the interactive terminal would have handed you has to be rebuilt outside the agent, in the runner configuration or the surrounding script.

qwen serve and the Web UI are both labelled experimental

The daemon path is `qwen serve`, which accepts clients over HTTP and SSE, a protocol the project calls ACP, and `qwen serve --open` launches the Web UI in a browser. Both carry an experimental marker in the README, and the daemon guide is a separate document from the authentication and settings guides. Consequence: do not put a production service, a shared internal endpoint, or a customer facing workflow on top of it. The versioned SDK packages are the layer that ships artifacts you can pin.

Cloning the repo builds a wider surface than npm actually ships

The workspace list in package.json does not include every package in the tree. package.json declares packages/* plus twelve channel packages, base, telegram, weixin, dingtalk, wecom, feishu, qqbot, github, dws, email, gitlab and plugin-example, alongside integrations/external-context and integrations/external-context-mem0, and it then subtracts three entries: !packages/desktop, !packages/live-host and !packages/mobile-shell. The desktop app, the live host and the mobile shell exist in the tree but are not members of the installable set. Consequence: a workspace install from a clone does not treat those three packages as workspace members.

Workspace channel packages outnumber the chat bridges with guides

Beyond the terminal the project lists a Desktop download for macOS, Windows and Linux, editor integrations for VS Code, Zed and JetBrains, and four chat bridges you start with `qwen channel start`: Telegram, DingTalk, WeChat and Feishu, each with its own documentation page. The workspace list carries more channels than that table documents, since wecom, qqbot, github, dws, email, gitlab and plugin-example have no matching row. Consequence: a directory under packages/channels is not evidence that the adapter is finished or documented, and plugin-example is by definition a template. Trust the four bridges that have guides, and treat the rest as scaffolding until someone writes the page.

Nightly tags ship alongside every stable release

Releases here move nightly as well as by version. The current cycle shows v0.26.6 published on 2026-11-02, followed the same day by sdk-typescript-v0.1.27 and v0.26.5-nightly.20261102.0441faff21, and the last push to main landed on 2026-11-02. The version field in package.json matches the stable tag, and the config block pins a sandbox image at that same number, ghcr.io/qwenlm/qwen-code:0.26.6. Consequence: pin a version when reproducibility matters. The Dockerfile builds on a digest pinned node:22-slim and sets QWEN_SKIP_PREPARE=1 so the install prepare step does not bundle a second time.

Editorial conclusion

Reach for Qwen Code when you want Claude Code shaped tooling with the provider left open to you, and install it through npm or Homebrew rather than the curl pipe. Check your Node version first, pin an explicit version instead of tracking @latest, and keep the serve path out of anything that has to stay up.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes