@qwen-code/qwen-code 0.13.2 → 0.14.0-nightly.20260402.a5f17ee39

package/bundled/loop/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: loop
+description: Create a recurring loop that runs a prompt on a schedule. Usage - /loop 5m check the build, /loop check the PR every 30m, /loop run tests (defaults to 10m). /loop list to show jobs, /loop clear to cancel all.
+allowedTools:
+  - cron_create
+  - cron_list
+  - cron_delete
+---
+
+# /loop — schedule a recurring prompt
+
+## Subcommands
+
+If the input (after stripping the `/loop` prefix) is exactly one of these keywords, run the subcommand instead of scheduling:
+
+- **`list`** — call CronList and display the results. Done.
+- **`clear`** — call CronList, then call CronDelete for every job returned. Confirm how many were cancelled. Done.
+
+Otherwise, parse the input below into `[interval] <prompt…>` and schedule it with CronCreate.
+
+## Parsing (in priority order)
+
+1. **Leading token**: if the first whitespace-delimited token matches `^\d+[smhd]$` (e.g. `5m`, `2h`), that's the interval; the rest is the prompt.
+2. **Trailing "every" clause**: otherwise, if the input ends with `every <N><unit>` or `every <N> <unit-word>` (e.g. `every 20m`, `every 5 minutes`, `every 2 hours`), extract that as the interval and strip it from the prompt. Only match when what follows "every" is a time expression — `check every PR` has no interval.
+3. **Default**: otherwise, interval is `10m` and the entire input is the prompt.
+
+If the resulting prompt is empty, show usage `/loop [interval] <prompt>` and stop — do not call CronCreate.
+
+Examples:
+
+- `5m /babysit-prs` → interval `5m`, prompt `/babysit-prs` (rule 1)
+- `check the deploy every 20m` → interval `20m`, prompt `check the deploy` (rule 2)
+- `run tests every 5 minutes` → interval `5m`, prompt `run tests` (rule 2)
+- `check the deploy` → interval `10m`, prompt `check the deploy` (rule 3)
+- `check every PR` → interval `10m`, prompt `check every PR` (rule 3 — "every" not followed by time)
+- `5m` → empty prompt → show usage
+
+## Interval → cron
+
+Supported suffixes: `s` (seconds, rounded up to nearest minute, min 1), `m` (minutes), `h` (hours), `d` (days). Convert:
+
+| Interval pattern  | Cron expression        | Notes                                     |
+| ----------------- | ---------------------- | ----------------------------------------- |
+| `Nm` where N ≤ 59 | `*/N * * * *`          | every N minutes                           |
+| `Nm` where N ≥ 60 | `0 */H * * *`          | round to hours (H = N/60, must divide 24) |
+| `Nh` where N ≤ 23 | `0 */N * * *`          | every N hours                             |
+| `Nd`              | `0 0 */N * *`          | every N days at midnight local            |
+| `Ns`              | treat as `ceil(N/60)m` | cron minimum granularity is 1 minute      |
+
+**If the interval doesn't cleanly divide its unit** (e.g. `7m` → `*/7 * * * *` gives uneven gaps at :56→:00; `90m` → 1.5h which cron can't express), pick the nearest clean interval and tell the user what you rounded to before scheduling.
+
+## Action
+
+1. Call CronCreate with:
+   - `cron`: the expression from the table above
+   - `prompt`: the parsed prompt from above, verbatim (slash commands are passed through unchanged)
+   - `recurring`: `true`
+2. Briefly confirm: what's scheduled, the cron expression, the human-readable cadence, that recurring tasks auto-expire after 3 days, and that they can cancel sooner with CronDelete (include the job ID).
+3. **Then immediately execute the parsed prompt now** — don't wait for the first cron fire. If it's a slash command, invoke it via the Skill tool; otherwise act on it directly.
+
+## Input

package/bundled/qc-helper/docs/extension/extension-releasing.md

@@ -1,11 +1,12 @@
 # Extension Releasing
 
-There are two primary ways of releasing extensions to users:
+There are three primary ways of releasing extensions to users:
 
 - [Git repository](#releasing-through-a-git-repository)
 - [Github Releases](#releasing-through-github-releases)
+- [npm Registry](#releasing-through-npm-registry)
 
-Git repository releases tend to be the simplest and most flexible approach, while GitHub releases can be more efficient on initial install as they are shipped as single archives instead of requiring a git clone which downloads each file individually. Github releases may also contain platform specific archives if you need to ship platform specific binary files.
+Git repository releases tend to be the simplest and most flexible approach, while GitHub releases can be more efficient on initial install as they are shipped as single archives instead of requiring a git clone which downloads each file individually. Github releases may also contain platform specific archives if you need to ship platform specific binary files. npm registry releases are ideal for teams that already use npm for package distribution, especially with private registries.
 
 ## Releasing through a git repository
 
@@ -119,3 +120,85 @@ jobs:
             release/linux.arm64.my-tool.tar.gz
             release/win32.arm64.my-tool.zip
 ```
+
+## Releasing through npm registry
+
+You can publish Qwen Code extensions as scoped npm packages (e.g. `@your-org/my-extension`). This is a good fit when:
+
+- Your team already uses npm for package distribution
+- You need private registry support with existing auth infrastructure
+- You want version resolution and access control handled by npm
+
+### Package requirements
+
+Your npm package must include a `qwen-extension.json` file at the package root. This is the same config file used by all Qwen Code extensions — the npm tarball is simply another delivery mechanism.
+
+A minimal package structure looks like:
+
+```
+my-extension/
+├── package.json
+├── qwen-extension.json
+├── QWEN.md              # optional context file
+├── commands/             # optional custom commands
+├── skills/               # optional custom skills
+└── agents/               # optional custom subagents
+```
+
+Make sure `qwen-extension.json` is included in your published package (i.e. not excluded by `.npmignore` or the `files` field in `package.json`).
+
+### Publishing
+
+Use standard npm publishing tools:
+
+```bash
+# Publish to the default registry
+npm publish
+
+# Publish to a private/custom registry
+npm publish --registry https://your-registry.com
+```
+
+### Installation
+
+Users install your extension using the scoped package name:
+
+```bash
+# Install latest version
+qwen extensions install @your-org/my-extension
+
+# Install a specific version
+qwen extensions install @your-org/my-extension@1.2.0
+
+# Install from a custom registry
+qwen extensions install @your-org/my-extension --registry https://your-registry.com
+```
+
+### Update behavior
+
+- Extensions installed without a version pin (e.g. `@scope/pkg`) track the `latest` dist-tag.
+- Extensions installed with a dist-tag (e.g. `@scope/pkg@beta`) track that specific tag.
+- Extensions pinned to an exact version (e.g. `@scope/pkg@1.2.0`) are always considered up-to-date and will not prompt for updates.
+
+### Authentication for private registries
+
+Qwen Code reads npm auth credentials automatically:
+
+1. **`NPM_TOKEN` environment variable** — highest priority
+2. **`.npmrc` file** — supports both host-level and path-scoped `_authToken` entries (e.g. `//your-registry.com/:_authToken=TOKEN` or `//pkgs.dev.azure.com/org/_packaging/feed/npm/registry/:_authToken=TOKEN`)
+
+`.npmrc` files are read from the current directory and the user's home directory.
+
+### Managing release channels
+
+You can use npm dist-tags to manage release channels:
+
+```bash
+# Publish a beta release
+npm publish --tag beta
+
+# Users install beta channel
+qwen extensions install @your-org/my-extension@beta
+```
+
+This works similarly to git branch-based release channels but uses npm's native dist-tag mechanism.

package/bundled/qc-helper/docs/extension/introduction.md

@@ -12,11 +12,11 @@ We offer a suite of extension management tools using both `qwen extensions` CLI
 
 You can manage extensions at runtime within the interactive CLI using `/extensions` slash commands. These commands support hot-reloading, meaning changes take effect immediately without restarting the application.
 
-| Command                               | Description                                                       |
-| ------------------------------------- | ----------------------------------------------------------------- |
-| `/extensions` or `/extensions manage` | Manage all installed extensions                                   |
-| `/extensions install <source>`        | Install an extension from a git URL, local path, or marketplace   |
-| `/extensions explore [source]`        | Open extensions source page(Gemini or ClaudeCode) in your browser |
+| Command                               | Description                                                                  |
+| ------------------------------------- | ---------------------------------------------------------------------------- |
+| `/extensions` or `/extensions manage` | Manage all installed extensions                                              |
+| `/extensions install <source>`        | Install an extension from a git URL, local path, npm package, or marketplace |
+| `/extensions explore [source]`        | Open extensions source page(Gemini or ClaudeCode) in your browser            |
 
 ### CLI Extension Management
 
@@ -89,6 +89,34 @@ Gemini extensions are automatically converted to Qwen Code format during install
 - TOML command files are automatically migrated to Markdown format
 - MCP servers, context files, and settings are preserved
 
+#### From npm Registry
+
+Qwen Code supports installing extensions from npm registries using scoped package names. This is ideal for teams with private registries that already have auth, versioning, and publishing infrastructure in place.
+
+```bash
+# Install the latest version
+qwen extensions install @scope/my-extension
+
+# Install a specific version
+qwen extensions install @scope/my-extension@1.2.0
+
+# Install from a custom registry
+qwen extensions install @scope/my-extension --registry https://your-registry.com
+```
+
+Only scoped packages (`@scope/package-name`) are supported to avoid ambiguity with the `owner/repo` GitHub shorthand format.
+
+**Registry resolution** follows this priority:
+
+1. `--registry` CLI flag (explicit override)
+2. Scoped registry from `.npmrc` (e.g. `@scope:registry=https://...`)
+3. Default registry from `.npmrc`
+4. Fallback: `https://registry.npmjs.org/`
+
+**Authentication** is handled automatically via the `NPM_TOKEN` environment variable or registry-specific `_authToken` entries in your `.npmrc` file.
+
+> **Note:** npm extensions must include a `qwen-extension.json` file at the package root, following the same format as any other Qwen Code extension. See [Extension Releasing](./extension-releasing.md#releasing-through-npm-registry) for packaging details.
+
 #### From Git Repository
 
 ```bash
@@ -127,7 +155,7 @@ This is useful if you have an extension disabled at the top-level and only enabl
 
 ### Updating an extension
 
-For extensions installed from a local path or a git repository, you can explicitly update to the latest version (as reflected in the `qwen-extension.json` `version` field) with `qwen extensions update extension-name`.
+For extensions installed from a local path, a git repository, or an npm registry, you can explicitly update to the latest version with `qwen extensions update extension-name`. For npm extensions installed without a version pin (e.g. `@scope/pkg`), updates check the `latest` dist-tag. For those installed with a specific dist-tag (e.g. `@scope/pkg@beta`), updates track that tag. Extensions pinned to an exact version (e.g. `@scope/pkg@1.2.0`) are always considered up-to-date.
 
 You can update all extensions with:
 
@@ -156,6 +184,12 @@ The `qwen-extension.json` file contains the configuration for the extension. The
       "command": "node my-server.js"
     }
   },
+  "channels": {
+    "my-platform": {
+      "entry": "dist/index.js",
+      "displayName": "My Platform Channel"
+    }
+  },
   "contextFileName": "QWEN.md",
   "commands": "commands",
   "skills": "skills",
@@ -175,6 +209,7 @@ The `qwen-extension.json` file contains the configuration for the extension. The
 - `version`: The version of the extension.
 - `mcpServers`: A map of MCP servers to configure. The key is the name of the server, and the value is the server configuration. These servers will be loaded on startup just like MCP servers configured in a [`settings.json` file](./cli/configuration.md). If both an extension and a `settings.json` file configure an MCP server with the same name, the server defined in the `settings.json` file takes precedence.
   - Note that all MCP server configuration options are supported except for `trust`.
+- `channels`: A map of custom channel adapters. The key is the channel type name, and the value has an `entry` (path to compiled JS entry point) and optional `displayName`. The entry point must export a `plugin` object conforming to the `ChannelPlugin` interface. See [Channel Plugins](../features/channels/plugins) for a full guide.
 - `contextFileName`: The name of the file that contains the context for the extension. This will be used to load the context from the extension directory. If this property is not used but a `QWEN.md` file is present in your extension directory, then that file will be loaded.
 - `commands`: The directory containing custom commands (default: `commands`). Commands are `.md` files that define prompts.
 - `skills`: The directory containing custom skills (default: `skills`). Skills are discovered automatically and become available via the `/skills` command.

package/bundled/qc-helper/docs/features/_meta.ts

@@ -13,5 +13,7 @@ export default {
   'token-caching': 'Token Caching',
   sandbox: 'Sandboxing',
   language: 'i18n',
+  channels: 'Channels',
   hooks: 'Hooks',
+  'scheduled-tasks': 'Scheduled Tasks',
 };

package/bundled/qc-helper/docs/features/channels/_meta.ts

@@ -0,0 +1,7 @@
+export default {
+  overview: 'Overview',
+  telegram: 'Telegram',
+  weixin: 'WeChat',
+  dingtalk: 'DingTalk',
+  plugins: 'Plugins',
+};

package/bundled/qc-helper/docs/features/channels/dingtalk.md

@@ -0,0 +1,134 @@
+# DingTalk (Dingtalk)
+
+This guide covers setting up a Qwen Code channel on DingTalk (钉钉).
+
+## Prerequisites
+
+- A DingTalk organization account
+- A DingTalk bot application with AppKey and AppSecret (see below)
+
+## Creating a Bot
+
+1. Go to the [DingTalk Developer Portal](https://open-dev.dingtalk.com)
+2. Create a new application (or use an existing one)
+3. Under the application, enable the **Robot** capability
+4. In Robot settings, enable **Stream Mode** (机器人协议 → Stream 模式)
+5. Note the **AppKey** (Client ID) and **AppSecret** (Client Secret) from the application credentials page
+
+### Stream Mode
+
+DingTalk Stream mode uses an outbound WebSocket connection — no public URL or server is needed. The bot connects to DingTalk's servers, which push messages through the WebSocket. This is the simplest deployment model.
+
+## Configuration
+
+Add the channel to `~/.qwen/settings.json`:
+
+```json
+{
+  "channels": {
+    "my-dingtalk": {
+      "type": "dingtalk",
+      "clientId": "$DINGTALK_CLIENT_ID",
+      "clientSecret": "$DINGTALK_CLIENT_SECRET",
+      "senderPolicy": "open",
+      "sessionScope": "user",
+      "cwd": "/path/to/your/project",
+      "instructions": "You are a concise coding assistant responding via DingTalk.",
+      "groupPolicy": "open",
+      "groups": {
+        "*": { "requireMention": true }
+      }
+    }
+  }
+}
+```
+
+Set the credentials as environment variables:
+
+```bash
+export DINGTALK_CLIENT_ID=<your-app-key>
+export DINGTALK_CLIENT_SECRET=<your-app-secret>
+```
+
+Or define them in the `env` section of `settings.json`:
+
+```json
+{
+  "env": {
+    "DINGTALK_CLIENT_ID": "your-app-key",
+    "DINGTALK_CLIENT_SECRET": "your-app-secret"
+  }
+}
+```
+
+## Running
+
+```bash
+# Start only the DingTalk channel
+qwen channel start my-dingtalk
+
+# Or start all configured channels together
+qwen channel start
+```
+
+Open DingTalk and send a message to the bot. You should see a 👀 emoji reaction appear while the agent processes, followed by the response.
+
+## Group Chats
+
+DingTalk bots work in both DM and group conversations. To enable group support:
+
+1. Set `groupPolicy` to `"allowlist"` or `"open"` in your channel config
+2. Add the bot to a DingTalk group
+3. @mention the bot in the group to trigger a response
+
+By default, the bot requires an @mention in group chats (`requireMention: true`). Set `"requireMention": false` for a specific group to make it respond to all messages. See [Group Chats](./overview#group-chats) for full details.
+
+### Finding a Group's Conversation ID
+
+DingTalk uses `conversationId` to identify groups. You can find it in the channel service logs when someone sends a message in the group — look for the `conversationId` field in the log output.
+
+## Images and Files
+
+You can send photos and documents to the bot, not just text.
+
+**Photos:** Send an image (screenshot, diagram, etc.) and the agent will analyze it using its vision capabilities. This requires a multimodal model — add `"model": "qwen3.5-plus"` (or another vision-capable model) to your channel config. DingTalk supports sending images directly or as part of rich text messages (mixed text + images).
+
+**Files:** Send a PDF, code file, or any document. The bot downloads it from DingTalk's servers and saves it locally so the agent can read it with its file tools. Audio and video files are also supported. This works with any model.
+
+## Key Differences from Telegram
+
+- **Authentication:** AppKey + AppSecret instead of a static bot token. The SDK manages access token refresh automatically.
+- **Connection:** WebSocket stream instead of polling — no public IP or webhook URL needed.
+- **Formatting:** Responses use DingTalk's markdown dialect (a limited subset). Tables are automatically converted to plain text since DingTalk doesn't render them. Long messages are split into chunks at ~3800 characters.
+- **Working indicator:** A 👀 emoji reaction is added to the user's message while processing, then removed when the response is sent.
+- **Media download:** Two-step process — a `downloadCode` from the message is exchanged for a temporary download URL via DingTalk's API.
+- **Groups:** DingTalk uses `isInAtList` for @mention detection instead of parsing message entities.
+
+## Tips
+
+- **Use DingTalk markdown-aware instructions** — DingTalk supports a limited markdown subset (headers, bold, links, code blocks, but not tables). Adding instructions like "Use DingTalk markdown. Avoid tables." helps the agent format responses correctly.
+- **Restrict access** — In an organization context, `senderPolicy: "open"` may be acceptable. For tighter control, use `"allowlist"` or `"pairing"`. See [DM Pairing](./overview#dm-pairing) for details.
+- **Referenced messages** — Quoting (replying to) a user message includes the quoted text as context for the agent. Quoting bot responses is not yet supported.
+
+## Troubleshooting
+
+### Bot doesn't connect
+
+- Verify your AppKey and AppSecret are correct
+- Check that the environment variables are set before running `qwen channel start`
+- Make sure **Stream Mode** is enabled in the bot's settings on the DingTalk Developer Portal
+- Check the terminal output for connection errors
+
+### Bot doesn't respond in groups
+
+- Check that `groupPolicy` is set to `"allowlist"` or `"open"` (default is `"disabled"`)
+- Make sure you @mention the bot in the group message
+- Verify the bot has been added to the group
+
+### "No sessionWebhook in message"
+
+This means DingTalk didn't include a reply endpoint in the message callback. This can happen if the bot's permissions are misconfigured. Check the bot's settings in the Developer Portal.
+
+### "Sorry, something went wrong processing your message"
+
+This usually means the agent encountered an error. Check the terminal output for details.