qwen-code/docs/developers/contributing.md
Dragon 4efe2c77bc
docs: add vertex-ai auth, missing commands, and qc-helper index entries (#5727)
* docs: add CLI subcommands section with qwen sessions list

- Add section 5 to commands.md for CLI-level subcommands
- Document qwen sessions list with --json and --limit flags
- Include output format, examples, and usage patterns

The sessions list command was added in commit 14e6ae8c2 but not documented.

* docs: add vertex-ai auth, missing commands, and qc-helper index entries

Audit docs/ against current codebase and fix high-impact drift:

- Add vertex-ai to auth.md, model-providers.md, and tos-privacy.md supported
  auth type tables (was missing from all three)
- Add missing slash commands to commands.md: /cd, /import-config, /workflows
- Add /doctor subcommands (memory, cpu-profile, rollback) and /extensions
  subcommands (list, manage, explore, install) to commands.md
- Add undocumented altNames: /clear→/reset,/new; /stats→/usage;
  /auth→/connect,/login; /resume→/continue; /compress→/summarize
- Add 8 missing feature entries to qc-helper SKILL.md topic index:
  code-review, followup-suggestions, tool-use-summaries, markdown-rendering,
  structured-output, dual-output, channels, tips
- Fix CLI binary name in contributing.md (qwen-code → qwen)

* docs: resolve review feedback on auth count, /workflows usage, GOOGLE_MODEL example

- auth.md: correct intro count from 'four' to 'three' methods (3 bullets + 3 Options; Vertex AI is a provider under API Key)
- commands.md: add '/workflows <runId>' to usage column to match argumentHint '[runId]'
- model-providers.md: add required GOOGLE_MODEL to the Vertex AI env example so it matches the prose and modelConfigUtils requirement

* docs: remove duplicate /workflows row introduced by main merge

main already documents /workflows (with the <runId> usage); the branch
merge kept both rows, leaving a duplicate in the Tool and Model
Management table. Drop the redundant row added by this PR.

* docs: resolve review feedback — /extensions explore source arg, CLI-name remnants

- commands.md: /extensions explore requires a <source> (exploreAction errors 'Unknown extensions source' without it)
- contributing.md: finish the qwen-code -> qwen CLI rename on the debug note (binary + .qwen config dir); repo-name references left intact

* docs: resolve review feedback — Vertex AI in tos-privacy, /doctor rollback clarity

- tos-privacy.md: propagate Vertex AI (which the header already counts as the 4th method) into the Data Collection list, FAQ Q1 and Q3, and add a '4. If you are using Vertex AI' section pointing to Google Cloud terms — fixes the four-vs-three internal inconsistency
- commands.md: clarify /doctor rollback rolls back the standalone CLI binary (standalone installs only) and disambiguate from /rewind's rollback alias (doctorCommand.ts gates on isStandalone)

* docs: resolve review feedback — clear semantics, doctor argHints, arrow spacing

- /clear: fix description to 'Clear conversation history and free up context' and drop the misleading '(shortcut: Ctrl+L)' grouping; Ctrl+L only clears the screen (clearScreen), it does not reset the session like /clear (clearCommand.ts)
- Ctrl/cmd+L keyboard row: clarify it clears the visible screen only, not 'Equivalent to /clear'
- /doctor memory and /doctor cpu-profile: surface the full argumentHints ([--sample] [--snapshot], [--duration <seconds>]) from doctorCommand.ts
- normalize section 1.4 arrow subcommands to spaced '→ ' style (approval-mode rows were the lone outliers)

* docs: resolve review feedback — enumerate /extensions explore sources

List the two valid sources (Gemini, ClaudeCode) from EXTENSION_EXPLORE_URL in extensionsCommand.ts so users can discover them without trial and error.

* docs: resolve review feedback — add extensions install security warning

/extensions install (extensionsCommand.ts) installs arbitrary git repos/paths with no confirmation prompt; add a warning that extensions run with full Qwen Code permissions and should only come from trusted sources.

* docs: resolve review feedback — add /stats subcommands, /auth aliases in 1.11

- commands.md: add /stats daily, /stats monthly, /stats export rows (registered in statsCommand.ts with day/month aliases and --format csv|json)
- section 1.11: note /auth's /connect and /login aliases (parallel to section 1.4)

* docs: resolve review feedback — /stats export full args, /summarize note

- /stats export: show the full argumentHint ([date|month] and [--output path]) from statsCommand.ts
- add a note disambiguating /summarize (alias of /compress, destructive) from /summary (project summary)

* docs: resolve review feedback — complete /arena /ide /directory /voice /mcp usage

Add the missing subcommands/arguments shown in the command sources:
- /arena: stop, select (arenaCommand.ts)
- /ide: enable, disable (ideCommand.ts)
- /directory: show (directoryCommand.tsx)
- /voice: hold, tap, off (voice-command.ts argumentHint)
- /mcp: nodesc, schema, auth, noauth (mcpCommand.ts argumentHint)

* docs: resolve review feedback — arena/stats aliases, trim /stats description

- /arena select: note alias 'choose' (arenaCommand.ts)
- /stats daily, /stats monthly: label day/month as aliases (statsCommand.ts)
- /stats: trim the description to a terse behavior-focused line (drop volatile tab names/keyboard shortcuts that belong in the dashboard help)

* docs: resolve review feedback — /copy args, /doctor memory --snapshot warning

- /copy: document language/latex/mermaid/index selection (copyCommand.ts argumentHint)
- add a warning that /doctor memory --snapshot writes a heap snapshot with sensitive data (matches doctorCommand.ts runtime warning)

* docs: resolve review feedback — mcp/approval-mode/copy accuracy, qwen privacy URL

- /mcp: drop deprecated auth/noauth (mcpCommand.ts argumentHint is now desc|nodesc|schema; auth/noauth are stubs)
- /approval-mode: drop nonexistent --project (mode is session-only), show actual invocations, add a safety warning for auto-edit/auto/yolo
- /copy: note N = Nth-last reply (copyCommand.ts)
- tos-privacy: unify Qwen Privacy Policy URL to qwen.ai/privacypolicy

* docs: resolve review feedback — import-config args + feature-gated commands note

- /import-config: show 'all' (default source) and enumerate --scope user|project (importConfigCommand.ts)
- add a note that /workflows, /lsp, /trust register only when their feature setting is enabled (BuiltinCommandLoader.ts gates them, default off)

* docs: fix feature-gating mechanisms + restore /stats tab names

- Correct the /workflows/lsp/trust note: actual gates are QWEN_CODE_ENABLE_WORKFLOWS=1 (env),
  --experimental-lsp (CLI flag), and security.folderTrust.enabled (setting) — the prior
  workflowsEnabled/lsp.enabled/folderTrust keys did not exist
- /stats: restore the Session/Activity/Efficiency tab names (dashboard contents are not
  documented elsewhere); keep volatile keyboard hints out per the earlier review

---------

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
2026-06-25 06:58:10 +00:00

9.9 KiB

How to Contribute

We would love to accept your patches and contributions to this project.

Contribution Process

Code Reviews

All submissions, including submissions by project members, require review. We use GitHub pull requests for this purpose.

Pull Request Guidelines

To help us review and merge your PRs quickly, please follow these guidelines. PRs that do not meet these standards may be closed.

All PRs should be linked to an existing issue in our tracker. This ensures that every change has been discussed and is aligned with the project's goals before any code is written.

  • For bug fixes: The PR should be linked to the bug report issue.
  • For features: The PR should be linked to the feature request or proposal issue that has been approved by a maintainer.

If an issue for your change doesn't exist, please open one first and wait for feedback before you start coding.

2. Keep It Small and Focused

We favor small, atomic PRs that address a single issue or add a single, self-contained feature.

  • Do: Create a PR that fixes one specific bug or adds one specific feature.
  • Don't: Bundle multiple unrelated changes (e.g., a bug fix, a new feature, and a refactor) into a single PR.

As a rule of thumb, start splitting a PR once it exceeds about 1,200 changed lines. PRs above about 2,000 changed lines should either be split into a series of smaller, logical PRs that can be reviewed and merged independently, or explain in the PR description why the change needs to land together.

3. Use Draft PRs for Work in Progress

If you'd like to get early feedback on your work, please use GitHub's Draft Pull Request feature. This signals to the maintainers that the PR is not yet ready for a formal review but is open for discussion and initial feedback.

4. Ensure All Checks Pass

Before submitting your PR, ensure that all automated checks are passing by running npm run preflight. This command runs all tests, linting, and other style checks.

5. Update Documentation

If your PR introduces a user-facing change (e.g., a new command, a modified flag, or a change in behavior), you must also update the relevant documentation in the /docs directory.

6. Write Clear Commit Messages and a Good PR Description

Your PR should have a clear, descriptive title and a detailed description of the changes. Follow the Conventional Commits standard for your commit messages.

  • Good PR Title: feat(cli): Add --json flag to 'config get' command
  • Bad PR Title: Made some changes

In the PR description, explain the "why" behind your changes and link to the relevant issue (e.g., Fixes #123).

Development Setup and Workflow

This section guides contributors on how to build, modify, and understand the development setup of this project.

Setting Up the Development Environment

Prerequisites:

  1. Node.js:
    • Development: Please use Node.js >=22. Ink 7 (used by the TUI) requires Node 22, and react@^19.2.0 is the matching peer. You can use a tool like nvm to manage Node.js versions.
    • Production: For running the CLI in a production environment, any version of Node.js >=22 is acceptable.
  2. Git

Build Process

To clone the repository:

git clone https://github.com/QwenLM/qwen-code.git # Or your fork's URL
cd qwen-code

To install dependencies defined in package.json as well as root dependencies:

npm install

To build the entire project (all packages):

npm run build

This command typically compiles TypeScript to JavaScript, bundles assets, and prepares the packages for execution. Refer to scripts/build.js and package.json scripts for more details on what happens during the build.

Enabling Sandboxing

Sandboxing is highly recommended and requires, at a minimum, setting QWEN_SANDBOX=true in your ~/.env and ensuring a sandboxing provider (e.g. macOS Seatbelt, docker, or podman) is available. See Sandboxing for details.

To build both the qwen CLI utility and the sandbox container, run build:all from the root directory:

npm run build:all

To skip building the sandbox container, you can use npm run build instead.

Running

To start the Qwen Code application from the source code (after building), run the following command from the root directory:

npm start

If you'd like to run the source build outside of the qwen-code folder, you can utilize npm link path/to/qwen-code/packages/cli (see: docs) to run with qwen

Running Tests

This project contains two types of tests: unit tests and integration tests.

Unit Tests

To execute the unit test suite for the project:

npm run test

This will run tests located in the packages/core and packages/cli directories. Ensure tests pass before submitting any changes. For a more comprehensive check, it is recommended to run npm run preflight.

Integration Tests

The integration tests are designed to validate the end-to-end functionality of Qwen Code. They are not run as part of the default npm run test command.

To run the integration tests, use the following command:

npm run test:e2e

For more detailed information on the integration testing framework, please see the Integration Tests documentation.

Linting and Preflight Checks

To ensure code quality and formatting consistency, run the preflight check:

npm run preflight

This command will run ESLint, Prettier, all tests, and other checks as defined in the project's package.json.

ProTip

after cloning create a git precommit hook file to ensure your commits are always clean.

echo "
# Run npm build and check for errors
if ! npm run preflight; then
  echo "npm build failed. Commit aborted."
  exit 1
fi
" > .git/hooks/pre-commit && chmod +x .git/hooks/pre-commit

Formatting

To separately format the code in this project by running the following command from the root directory:

npm run format

This command uses Prettier to format the code according to the project's style guidelines.

Linting

To separately lint the code in this project, run the following command from the root directory:

npm run lint

Coding Conventions

  • Please adhere to the coding style, patterns, and conventions used throughout the existing codebase.
  • Imports: Pay special attention to import paths. The project uses ESLint to enforce restrictions on relative imports between packages.

Project Structure

  • packages/: Contains the individual sub-packages of the project.
    • cli/: The command-line interface.
    • core/: The core backend logic for Qwen Code.
  • docs/: Contains all project documentation.
  • scripts/: Utility scripts for building, testing, and development tasks.

For more detailed architecture, see docs/architecture.md.

Documentation Development

This section describes how to develop and preview the documentation locally.

Prerequisites

  1. Ensure you have Node.js (version 22+) installed
  2. Have npm or yarn available

Setup Documentation Site Locally

To work on the documentation and preview changes locally:

  1. Navigate to the docs-site directory:

    cd docs-site
    
  2. Install dependencies:

    npm install
    
  3. Link the documentation content from the main docs directory:

    npm run link
    

    This creates a symbolic link from ../docs to content in the docs-site project, allowing the documentation content to be served by the Next.js site.

  4. Start the development server:

    npm run dev
    
  5. Open http://localhost:3000 in your browser to see the documentation site with live updates as you make changes.

Any changes made to the documentation files in the main docs directory will be reflected immediately in the documentation site.

Debugging

VS Code:

  1. Run the CLI to interactively debug in VS Code with F5
  2. Start the CLI in debug mode from the root directory:
    npm run debug
    
    This command runs node --inspect-brk dist/index.js within the packages/cli directory, pausing execution until a debugger attaches. You can then open chrome://inspect in your Chrome browser to connect to the debugger.
  3. In VS Code, use the "Attach" launch configuration (found in .vscode/launch.json).

Alternatively, you can use the "Launch Program" configuration in VS Code if you prefer to launch the currently open file directly, but 'F5' is generally recommended.

To hit a breakpoint inside the sandbox container run:

DEBUG=1 qwen

Note: If you have DEBUG=true in a project's .env file, it won't affect qwen due to automatic exclusion. Use .qwen/.env files for qwen-specific debug settings.

React DevTools

To debug the CLI's React-based UI, you can use React DevTools. Ink, the library used for the CLI's interface, is compatible with React DevTools version 4.x.

  1. Start the Qwen Code application in development mode:

    DEV=true npm start
    
  2. Install and run React DevTools version 4.28.5 (or the latest compatible 4.x version):

    You can either install it globally:

    npm install -g react-devtools@4.28.5
    react-devtools
    

    Or run it directly using npx:

    npx react-devtools@4.28.5
    

    Your running CLI application should then connect to React DevTools.

Sandboxing

TBD

Manual Publish

We publish an artifact for each commit to our internal registry. But if you need to manually cut a local build, then run the following commands:

npm run clean
npm install
npm run auth
npm run prerelease:dev
npm publish --workspaces