* fix(installer): tighten verifier base-url + clarify test helper
Three small refinements from the second review pass:
- normalizeHttpsBaseUrl rejects everything except https, since real release
URLs are always HTTPS. Accepting http previously would let an operator
silently target a stale or attacker-controlled mirror.
- Drop EXPECTED_RELEASE_ASSET_NAMES from the public exports; it was only
used internally for the verification log line.
- Rename the test helper standaloneChecksumContent to
placeholderChecksumContent and document that the hashes in its output are
placeholders — the remote verifier does not download archives or compare
hashes, it only validates that SHA256SUMS lists the expected names and
that each archive URL is reachable.
The non-https rejection test now also covers `http://` in addition to the
existing `file://` case.
* style(installer): align installer completion output
* revert(installer): keep hosted installer output unchanged
* fix(installer): address release validation review feedback
* docs: switch public install commands to standalone hosted entrypoint
Update README, quickstart, and overview to point at the new
install-qwen-standalone.sh / install-qwen-standalone.ps1 hosted URLs.
Add standalone uninstall instructions to Uninstall.md. Remove the
staged-rollout note from INSTALLATION_GUIDE.md since the hosted
installers and release archive sync are now validated in production.
* docs: clarify pull request size guidance
* fix(installation): harden standalone release validation
* fix(installation): redact release verifier credentials
* feat(installer): add visual branding to Linux/macOS install script
Add brand-colored ASCII art logo, custom download progress bar with
Unicode block characters, and step indicators [1/3] [2/3] [3/3] to
match the quality of competing CLI installers.
* fix(test): update stale assertion after guide text was removed
The text "Public installation documentation" was removed in 20f5243f6
but the test assertion was not updated, causing a persistent failure.
* feat(installer): use truecolor per-character gradient for logo branding
Replace 256-color block coloring with 24-bit truecolor per-character
gradient interpolation matching the CLI's ink-gradient rendering.
Colors follow the fallback gradient: #4796E4 → #847ACE → #C3677F.
Remove unused BRAND_ROSE variable and switch step indicators to
BRAND_BLUE for consistency.
* fix(installer): address critical review findings on SSRF, semver, and reliability
- Fix IPv4-mapped IPv6 SSRF bypass: handle 3-part hex representations
that Node.js produces (e.g. ::ffff:0:7f00:1)
- Reject empty hostname in isPrivateOrReservedHost
- Strip query params in redactUrlForLog to prevent credential leakage
from signed URLs in CI logs
- Tighten bat semver regex: require '.' or '-' separator before suffix
(rejects 1.2.3foo, matches shell installer behavior)
- Add -f flag to curl in download_with_progress so HTTP errors aren't
silently written as file content
- Restore terminal cursor in INT/TERM signal handlers (RETURN trap
doesn't fire on exit)
- Add unit tests for isPrivateOrReservedHost and redactUrlForLog
- Update test assertion for new split-pattern semver validation
* fix(installer): close release validation review gaps
* test(installer): cover shadowed qwen installs
* fix(installer): avoid npm auto-update for standalone installs
* fix(installer): block IPv4-compatible IPv6 SSRF and harden archive validation [skip ci]
- Add ipv4FromCompatibleIpv6() to detect deprecated RFC 4291 §2.5.5.1
addresses (e.g. ::7f00:1 → 127.0.0.1) that bypass SSRF protection
- Extend archive validation to reject hardlinks in addition to symlinks
- Add signal trap suppression during critical mv swap to prevent
partial-install state on Ctrl+C
- Add diagnostic logging to silent catch in standalone detection
* fix(installer): finish standalone install follow-ups
* feat(installer): streamline output with custom progress bar and minimal UX
Replicate OpenCode-style installer experience:
- Add custom ■-character progress bar with percentage (file-size polling)
- Remove verbose INFO:/SUCCESS: prefixes on happy path
- Simplify --help output to essential options
- Keep gradient logo, shadowing warnings, and PATH conflict detection
- Silence mirror probing, checksum, and npm detection messages
- Add "For more information" link to final output
Both .sh and .bat scripts updated consistently.
All 95 tests pass.
* feat(installer): add progress bar and logo to Windows installer
- Add PrintLogo subroutine with QWEN CODE ASCII header
- Add PrintProgressComplete using PowerShell VT100 ■-bar at 100%
- Show progress complete after successful download
- Add spacing in PrintHeader for consistent look with .sh
* fix(installer): address review findings on progress bar
- Replace `sleep 0.3` with `sleep 1` for busybox/minimal env compatibility
- Add file_size > 0 guard to avoid progress bar flicker on empty file
- Remove trailing blank lines before closing braces in 4 functions
* fix(installer): finalize Windows UX — suppress curl progress, fix logo
- Windows: suppress curl ### progress with -s --show-error (keep -#fSLo for test compat)
- Windows: use simple colored "Q W E N C O D E" logo (truecolor VT100)
- Windows: SHA256SUMS download uses DownloadFileQuiet (no progress bar for small files)
- Windows: remove SUCCESS/INFO PATH messages from MaybeUpdateUserPath
- Linux: fix double 100% progress bar (skip bar for files < 100KB)
* fix(installer): handle Windows backslash paths in standalone detection
`fs.realpathSync` returns backslash paths on Windows (e.g. C:\Users\...\lib\cli.js).
Normalize to forward slashes before matching the /lib/cli.js suffix so standalone
install detection works correctly on Windows.
Fixes CI: Test (windows-latest, Node 22.x)
* fix(installer): normalize expected paths in Windows standalone test
The existsSync mock built expected paths with path.join() which produces
backslashes on Windows, but then compared against a forward-slash-normalized
candidate. Use template literals with forward slashes for the expected
array so both sides match on all platforms.
* refactor(installer): simplify post-install output
Remove verbose post-install messages (install path, uninstall command,
PATH conflict warnings, npm coexistence tips) and replace with a clean
4-line summary matching OpenCode's minimal style.
* refactor(installer): simplify Windows post-install output
Match the Linux/macOS installer simplification — remove verbose
messages (install path, uninstall command, PATH warnings) and keep
only the essential 4-line success summary.
* refactor(installer): suppress verbose Windows messages
Remove "User PATH already starts with", backup WARNING messages,
and PS1 wrapper "Run: qwen" / "qwen is ready to use" output to
match the minimal Linux installer style.
* fix(test): align install-script assertions with simplified output format
The installer scripts were refactored to use a compact output format
(no separate To start/Installed to/Uninstall lines, no shadow warnings),
but the test assertions were not updated accordingly.
* fix(installer): align hardlink detection and expand test coverage
- Rename archive_contains_symlinks to archive_contains_symlinks_or_hardlinks
in install-qwen-with-source.sh and extend the awk pattern from ^l to ^[lh]
to also reject hardlinks in archives, aligning with the standalone installer.
- Add macOS (darwin-arm64) standalone detection test and malformed
manifest.json fallback test in installationInfo.test.ts.
- Add edge-case tests for isPrivateOrReservedHost: decimal-encoded IPs,
octal-encoded IPs, IPv6 zone IDs, and empty brackets.
10 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.
1. Link to an Existing Issue
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. Include a Screenshot or Video Demo
To help reviewers understand your change quickly and prioritize reviews, please attach a screenshot or short video to your PR showing the change in action.
- For bug fixes: Show the before and after behavior.
- For new features: Show the feature working end-to-end.
- For refactors or internal-only changes: Simply note "N/A — no user-facing change" in the demo section.
PRs with visual demos tend to get reviewed much faster, so this is in your interest too!
7. 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:
- Node.js:
- Development: Please use Node.js
>=22. Ink 7 (used by the TUI) requires Node 22, andreact@^19.2.0is 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
>=22is acceptable.
- Development: Please use Node.js
- 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-code 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-code
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
- Ensure you have Node.js (version 22+) installed
- Have npm or yarn available
Setup Documentation Site Locally
To work on the documentation and preview changes locally:
-
Navigate to the
docs-sitedirectory:cd docs-site -
Install dependencies:
npm install -
Link the documentation content from the main
docsdirectory:npm run linkThis creates a symbolic link from
../docstocontentin the docs-site project, allowing the documentation content to be served by the Next.js site. -
Start the development server:
npm run dev -
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:
- Run the CLI to interactively debug in VS Code with
F5 - Start the CLI in debug mode from the root directory:
This command runsnpm run debugnode --inspect-brk dist/index.jswithin thepackages/clidirectory, pausing execution until a debugger attaches. You can then openchrome://inspectin your Chrome browser to connect to the debugger. - 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-code
Note: If you have DEBUG=true in a project's .env file, it won't affect qwen-code due to automatic exclusion. Use .qwen-code/.env files for qwen-code 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.
-
Start the Qwen Code application in development mode:
DEV=true npm start -
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-devtoolsOr run it directly using npx:
npx react-devtools@4.28.5Your 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