@qwen-code/qwen-code 0.24.5-preview.0 → 0.24.5

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

@@ -32,7 +32,7 @@ Add a channel to `~/.qwen/settings.json`:
     "dws-work": {
       "type": "dws",
       "profile": "profile-name-or-corp-id",
-      "senderPolicy": "pairing",
+      "privatePolicy": "pairing",
       "groupPolicy": "pairing",
       "watchTodos": true,
       "startReaction": "🤔",
@@ -55,7 +55,7 @@ without interactive confirmations:
   "channels": {
     "dws-answers": {
       "type": "dws",
-      "senderPolicy": "pairing",
+      "privatePolicy": "pairing",
       "groupPolicy": "pairing",
       "approvalMode": "yolo",
       "cwd": "/path/to/answer-bot"
@@ -67,15 +67,15 @@ without interactive confirmations:
 YOLO mode auto-approves every tool call. Use it only for a trusted bot account
 and workspace.
 
-`senderPolicy` and `groupPolicy` default to `pairing` for a newly managed DWS channel. `dmPolicy` defaults to `open`, including existing configurations that omit it. Approve a user or group with the code returned by the channel:
+New managed DWS channels default to `privatePolicy: "pairing"` and `groupPolicy: "pairing"`. Approve a user or group with the code returned by the channel:
 
 ```bash
 qwen channel pairing approve dws-work CODE
 ```
 
-`senderPolicy` controls direct-message senders, document-notification authors, native-todo creators, and senders in `open` or `allowlist` groups. `groupPolicy` controls group conversations. An approved pairing group follows the shared channel behavior and authorizes its members; open and allowlist groups must also pass `senderPolicy`.
+`privatePolicy` controls direct messages, document-notification authors, and native-todo creators. Document threads and native todos are personal requests; `groups.senders` never applies to them. `groupPolicy` controls group admission, and `groups["*"].senders` or a per-group override controls which members may start tasks. Group members default to `open`, independently of private access. Shared-session management requires explicit `operators`; see [Shared-Session Operators](./overview.md#shared-session-operators).
 
-Group and direct-message access can be configured independently. For a group-only channel, set `dmPolicy: "disabled"` and choose an enabled `groupPolicy`. For a direct-message-only channel, set `groupPolicy: "disabled"` and `dmPolicy: "open"`. Direct-message access also controls document notifications. Native todo polling remains controlled separately by `watchTodos`.
+For a group-only channel, set `privatePolicy: "disabled"` and enable `groupPolicy`. For a personal-only channel, set `groupPolicy: "disabled"` and enable `privatePolicy`. Disabled private access prevents direct messages, document notifications, and native todos from starting tasks; `watchTodos` separately enables todo polling. Deprecated `senderPolicy` and `dmPolicy` remain private-policy fallbacks only; see [Private Policy](./overview.md#private-policy).
 
 Disabled chat sources are not subscribed to or polled, and their messages cannot start new tasks through late callbacks or persisted replay. Pending work and history cursors are retained: after re-enabling a source, the existing recovery mechanism may process older messages, including messages from the disabled interval. Sender authorization, group pairing, and mention requirements still apply.
 
@@ -105,7 +105,7 @@ There is no document or knowledge-base watch list. To start a document task:
 
 The channel extracts the document ID, comment key, and request from that notification. It reads the referenced document for context, adds the configured start reaction while the task runs, and replies to the original document comment. The real-time DWS event stream is used when it contains the card; a five-second incremental history check covers cards omitted by the current event stream.
 
-Comments that do not generate a notification are ignored by design. Duplicate notification messages for the same document comment execute only once. Document tasks follow `senderPolicy` and support `approvalMode` `default`, `plan`, or `yolo`; `default` is used when omitted.
+Comments that do not generate a notification are ignored by design. Duplicate notification messages for the same document comment execute only once. Document tasks follow `privatePolicy` and support `approvalMode` `default`, `plan`, or `yolo`; `default` is used when omitted.
 
 ## Native Todo Changes
 
@@ -113,7 +113,7 @@ Set `watchTodos: true` to poll the selected DWS profile's pending native todos w
 
 The first successful scan establishes a baseline and does not start historical todos. Later scans run a task when a todo is newly assigned, reopened, or its actionable fields change, including its title, priority, deadline, or assignees. The final response is added as a comment on the originating todo. Comment-only metadata and modification timestamps are excluded from change detection so the channel's own response cannot trigger a loop. Completion or removal drops the todo from the pending set; reopening it creates a new trigger.
 
-Native todos follow `senderPolicy` using the todo creator identity. Under `pairing`, the channel adds one pairing-code comment and keeps the todo pending; after the creator is approved locally, a later poll can process the unchanged todo. Polling runs every 30 seconds and remains scoped to the pinned profile's current organization.
+Native todos follow `privatePolicy` using the todo creator identity. Under `pairing`, the channel adds one pairing-code comment and keeps the todo pending; after the creator is approved locally, a later poll can process the unchanged todo. Polling runs every 30 seconds and remains scoped to the pinned profile's current organization.
 
 ## Starting and Verifying
 

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

@@ -64,7 +64,7 @@ Add the channel to `~/.qwen/settings.json`:
       "type": "feishu",
       "clientId": "<your-app-id>",
       "clientSecret": "<your-app-secret>",
-      "senderPolicy": "open",
+      "privatePolicy": "open",
       "sessionScope": "user",
       "cwd": "/path/to/your/project",
       "groupPolicy": "open",

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

@@ -42,13 +42,16 @@ Add the channel to `~/.qwen/settings.json`:
       "useLocalGh": true,
       "pollInterval": 60000,
       "reasonFilter": ["mention", "review_requested", "assign"],
-      "senderPolicy": "allowlist",
-      "allowedUsers": ["operator-github-username"],
+      "operators": ["operator-github-username"],
       "sessionScope": "chat_thread",
       "cwd": "/path/to/your/project",
       "groupPolicy": "open",
       "groups": {
-        "*": { "requireMention": true }
+        "*": {
+          "requireMention": true,
+          "senders": "allowlist",
+          "allowedUsers": ["operator-github-username"]
+        }
       }
     }
   }
@@ -61,7 +64,7 @@ To override local `gh` authentication with a PAT, add `"token": "$GITHUB_TOKEN"`
 export GITHUB_TOKEN="ghp_your_token_here"
 ```
 
-The authenticated account cannot trigger its own channel. If that account needs to operate the channel, authenticate a separate bot account and put only operator accounts in `allowedUsers`. Startup rejects an allowlist containing only the authenticated account and warns when it appears alongside other operators.
+The authenticated account cannot trigger its own channel. If that account needs to operate the channel, authenticate a separate bot account and put their usernames in the group `allowedUsers` and explicit `operators` lists. Startup warns when a group allowlist contains the authenticated account, which cannot trigger tasks; use a different account in the group allowlist.
 
 ### GitHub Enterprise
 
@@ -84,7 +87,6 @@ Local `gh` authentication requires an HTTPS `baseUrl` so the daemon host credent
 | `pollInterval`            | `60000`                  | Poll interval in ms                                                                                                                              |
 | `baseUrl`                 | `https://api.github.com` | API base URL (for GHE)                                                                                                                           |
 | `groupPolicy`             | `"disabled"`             | Must be `"open"`, `"allowlist"` with the repo (`owner/repo`) listed in `groups`, or `"pairing"` with the repo approved for notifications to flow |
-| `senderPolicy`            | `"allowlist"`            | Who can trigger the bot                                                                                                                          |
 | `groups.*.requireMention` | `true`                   | Require @mentions for ordinary comments; directed notification reasons still run                                                                 |
 | `reasonFilter`            | unset                    | Optional allowlist of GitHub notification reasons to process                                                                                     |
 
@@ -96,13 +98,15 @@ Filtered notifications are marked read only after all accepted work in the poll
 
 ## ⚠️ Security
 
-On a **public repository**, setting `senderPolicy: "open"` allows **any GitHub user** who triggers a supported notification reason to submit prompts that drive the agent in your `cwd`. This includes reading code, spending tokens, posting comments, and (subject to permission policy) running tools.
+On a **public repository**, setting `groups: { "*": { "senders": "open" } }` allows **any GitHub user** who triggers a supported notification reason to submit prompts that drive the agent in your `cwd`. This includes reading code, spending tokens, posting comments, and (subject to permission policy) running tools.
 
-Always use `senderPolicy: "allowlist"` with explicit `allowedUsers` on public repos.
+Always use `groups["*"].senders: "allowlist"` with explicit group `allowedUsers` on public repos.
 
-Allowlist and pairing entries follow the **username**, not the immutable account ID. If an allowlisted user renames their GitHub account, remove the stale entry — GitHub releases the old username for anyone else to claim, and the new holder would inherit the allowlist/pairing authorization.
+All GitHub traffic is group traffic. Group members default to `open`; set `groups["*"].senders` to `allowlist` and populate its `allowedUsers` to restrict authors. Private policy and user pairing never restrict repository members. Set `operators` explicitly for shared-session management.
 
-Note that under `groupPolicy: "pairing"`, access is granted per repository: once a repository is approved, **any GitHub user** can drive the bot through that repository's issues and pull requests. All GitHub traffic is group traffic, so `senderPolicy` and `allowedUsers` do not gate members of an approved repository. Approvals are keyed by the repository full name (`owner/repo`), which changes on rename or transfer — revoke stale group approvals after any repository rename, transfer, or deletion.
+Group member allowlists and operator lists follow the **username**, not the immutable account ID. If a listed user renames their GitHub account, remove the stale entry — GitHub releases the old username for anyone else to claim, and the new holder would inherit that authorization.
+
+Note that under `groupPolicy: "pairing"`, access is granted per repository: once a repository is approved, **any GitHub user** can by default drive the bot through that repository's issues and pull requests. All GitHub traffic is group traffic, so `privatePolicy` and the top-level `allowedUsers` do not gate members of an approved repository; set `senders: "allowlist"` with `allowedUsers` on that repository's `groups` entry to narrow it. Approvals are keyed by the repository full name (`owner/repo`), which changes on rename or transfer — revoke stale group approvals after any repository rename, transfer, or deletion.
 
 ## Mention Detection
 

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

@@ -26,7 +26,13 @@ Add the channel to `~/.qwen/settings.json`:
       "type": "gitlab",
       "token": "$GITLAB_TOKEN",
       "pollInterval": 60000,
-      "senderPolicy": "open",
+      "operators": ["operator-gitlab-username"],
+      "groups": {
+        "*": {
+          "senders": "allowlist",
+          "allowedUsers": ["operator-gitlab-username"]
+        }
+      },
       "sessionScope": "chat_thread",
       "cwd": "/path/to/your/project",
       "groupPolicy": "open",
@@ -63,7 +69,6 @@ For self-hosted instances, set `baseUrl`:
 | `baseUrl`                | `https://gitlab.com`      | GitLab instance URL                                                                               |
 | `action_prompt_template` | (required for processing) | Maps GitLab action names to metadata templates                                                    |
 | `groupPolicy`            | `"disabled"`              | Must be `"open"`, `"allowlist"` with the project listed, or `"pairing"` with the project approved |
-| `senderPolicy`           | `"allowlist"`             | Who can trigger the bot                                                                           |
 
 ## action_prompt_template
 
@@ -128,11 +133,13 @@ You do **not** need a `%body%` variable — the comment/description text is alwa
 
 ## ⚠️ Security
 
-On a **public project**, setting `senderPolicy: "open"` allows **any GitLab user** who @mentions the bot to submit prompts that drive the agent in your `cwd`.
+On a **public project**, setting `groups: { "*": { "senders": "open" } }` allows **any GitLab user** who @mentions the bot to submit prompts that drive the agent in your `cwd`.
 
-Always use `senderPolicy: "allowlist"` with explicit `allowedUsers` on public projects.
+Always use `groups["*"].senders: "allowlist"` with explicit group `allowedUsers` on public projects.
 
-Note that under `groupPolicy: "pairing"`, access is granted per project: once a project is approved, **any GitLab user** can drive the bot through that project's issues and merge requests. All GitLab traffic is group traffic, so `senderPolicy` and `allowedUsers` do not gate members of an approved project. Approvals are keyed by the project path (`owner/repo`), which changes on rename or transfer — revoke stale group approvals after any project rename, transfer, or deletion.
+All GitLab traffic is group traffic. Group members default to `open`; set `groups["*"].senders` to `allowlist` and populate its `allowedUsers` to restrict authors. Private policy and user pairing never restrict repository members. Set `operators` explicitly for shared-session management.
+
+Note that under `groupPolicy: "pairing"`, access is granted per project: once a project is approved, **any GitLab user** can by default drive the bot through that project's issues and merge requests. All GitLab traffic is group traffic, so `privatePolicy` and the top-level `allowedUsers` do not gate members of an approved project; set `senders: "allowlist"` with `allowedUsers` on that project's `groups` entry to narrow it. Approvals are keyed by the project path (`owner/repo`), which changes on rename or transfer — revoke stale group approvals after any project rename, transfer, or deletion.
 
 ## Mention Detection
 

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

@@ -33,13 +33,12 @@ Channels are configured under the `channels` key in `settings.json`. Each channe
     "my-channel": {
       "type": "telegram",
       "token": "$MY_BOT_TOKEN",
-      "senderPolicy": "allowlist",
+      "privatePolicy": "allowlist",
       "allowedUsers": ["123456789"],
       "sessionScope": "user",
       "cwd": "/path/to/working/directory",
       "instructions": "Optional system instructions for the agent.",
       "groupPolicy": "disabled",
-      "dmPolicy": "open",
       "groups": {
         "*": { "requireMention": true }
       }
@@ -50,36 +49,86 @@ Channels are configured under the `channels` key in `settings.json`. Each channe
 
 ### Options
 
-| Option              | Required         | Description                                                                                                                                                                                                             |
-| ------------------- | ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `type`              | Yes              | Channel type: `telegram`, `weixin`, `qq`, `dingtalk`, `dws`, `wecom`, `feishu`, `github`, `gitlab`, or a custom type from an extension (see [Plugins](./plugins))                                                       |
-| `token`             | Telegram         | Bot token. Supports `$ENV_VAR` syntax to read from environment variables. Not needed for WeChat, DingTalk, WeCom, or Feishu                                                                                             |
-| `clientId`          | DingTalk, Feishu | DingTalk AppKey or Feishu App ID. Supports `$ENV_VAR` syntax                                                                                                                                                            |
-| `clientSecret`      | DingTalk, Feishu | DingTalk AppSecret or Feishu App Secret. Supports `$ENV_VAR` syntax                                                                                                                                                     |
-| `botId`             | WeCom            | WeCom intelligent robot Bot ID. Supports `$ENV_VAR` syntax. See [WeCom](./wecom)                                                                                                                                        |
-| `secret`            | WeCom            | WeCom intelligent robot Secret. Supports `$ENV_VAR` syntax. See [WeCom](./wecom)                                                                                                                                        |
-| `model`             | No               | Model to use for this channel (e.g., `qwen3.5-plus`). Overrides the default model. Useful for multimodal models that support image input                                                                                |
-| `senderPolicy`      | No               | Who can talk to the bot: `allowlist` (default), `open`, or `pairing`                                                                                                                                                    |
-| `allowedUsers`      | No               | List of user IDs allowed to use the bot (used by `allowlist` and `pairing` policies)                                                                                                                                    |
-| `sessionScope`      | No               | How sessions are scoped: `user` (default), `chat_thread`, or `single`. Legacy `thread` remains compatible when already configured but is not offered for new Web Shell configurations                                   |
-| `multiSession`      | No               | Retain up to eight owner-scoped named tasks in one chat. Requires daemon-managed mode, `sessionScope: "user"`, no webhooks or group-history backfill, and no enabled Channel loops                                      |
-| `cwd`               | No               | Working directory for the agent. Defaults to the current directory                                                                                                                                                      |
-| `approvalMode`      | No               | Tool approval mode for channel sessions. Unattended webhook tasks require `yolo`; the setting applies to every session on the channel                                                                                   |
-| `instructions`      | No               | Custom instructions prepended to the first message of each session                                                                                                                                                      |
-| `webhooks`          | No               | Webhook sources and delivery targets for daemon-managed channels. See [Webhook-triggered tasks](#webhook-triggered-tasks)                                                                                               |
-| `groupPolicy`       | No               | Group chat access: `disabled` (default), `allowlist`, `pairing`, or `open`. See [Group Chats](#group-chats)                                                                                                             |
-| `dmPolicy`          | No               | Private/DM access: `open` (default) or `disabled` (silently drop all DMs). Useful for group-only bots                                                                                                                   |
-| `groupHistoryLimit` | No               | Opt-in group history backfill. `0` or omitted disables it. A positive number persists that many unmentioned group messages from authorized senders or members of approved paired groups for the next bot mention/reply. |
-| `groups`            | No               | Per-group settings. Keys are group chat IDs or `"*"` for defaults. See [Group Chats](#group-chats)                                                                                                                      |
-| `dispatchMode`      | No               | What happens when you send a message while the bot is busy: `steer` (default), `collect`, or `followup`. See [Dispatch Modes](#dispatch-modes)                                                                          |
-
-### Sender Policy
-
-Controls who can interact with the bot:
-
-- **`allowlist`** (default) — Only users listed in `allowedUsers` can send messages. Others are silently ignored.
-- **`pairing`** — Unknown senders receive a pairing code. The bot operator approves them via CLI, and they're added to a persistent allowlist. Users in `allowedUsers` skip pairing entirely. See [DM Pairing](#dm-pairing) below.
-- **`open`** — Anyone can send messages. Use with caution.
+| Option              | Required         | Description                                                                                                                                                                                                 |
+| ------------------- | ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `type`              | Yes              | Channel type: `telegram`, `weixin`, `qq`, `dingtalk`, `dws`, `wecom`, `feishu`, `github`, `gitlab`, or a custom type from an extension (see [Plugins](./plugins))                                           |
+| `token`             | Telegram         | Bot token. Supports `$ENV_VAR` syntax to read from environment variables. Not needed for WeChat, DingTalk, WeCom, or Feishu                                                                                 |
+| `clientId`          | DingTalk, Feishu | DingTalk AppKey or Feishu App ID. Supports `$ENV_VAR` syntax                                                                                                                                                |
+| `clientSecret`      | DingTalk, Feishu | DingTalk AppSecret or Feishu App Secret. Supports `$ENV_VAR` syntax                                                                                                                                         |
+| `botId`             | WeCom            | WeCom intelligent robot Bot ID. Supports `$ENV_VAR` syntax. See [WeCom](./wecom)                                                                                                                            |
+| `secret`            | WeCom            | WeCom intelligent robot Secret. Supports `$ENV_VAR` syntax. See [WeCom](./wecom)                                                                                                                            |
+| `model`             | No               | Model to use for this channel (e.g., `qwen3.5-plus`). Overrides the default model. Useful for multimodal models that support image input                                                                    |
+| `privatePolicy`     | No               | Private access: `disabled`, `allowlist`, `pairing`, or `open`; new managed channels default to `pairing`                                                                                                    |
+| `allowedUsers`      | No               | Private user IDs allowed without pairing (used by private `allowlist` and `pairing` policies)                                                                                                               |
+| `sessionScope`      | No               | How sessions are scoped: `user` (default), `chat_thread`, or `single`. Legacy `thread` remains compatible when already configured but is not offered for new Web Shell configurations                       |
+| `multiSession`      | No               | Retain up to eight owner-scoped named tasks in one chat. Requires daemon-managed mode, `sessionScope: "user"`, no webhooks or group-history backfill, and no enabled Channel loops                          |
+| `cwd`               | No               | Working directory for the agent. Defaults to the current directory                                                                                                                                          |
+| `approvalMode`      | No               | Tool approval mode for channel sessions. Unattended webhook tasks require `yolo`; the setting applies to every session on the channel                                                                       |
+| `instructions`      | No               | Custom instructions prepended to the first message of each session                                                                                                                                          |
+| `webhooks`          | No               | Webhook sources and delivery targets for daemon-managed channels. See [Webhook-triggered tasks](#webhook-triggered-tasks)                                                                                   |
+| `groupPolicy`       | No               | Group chat access: `disabled` (default), `allowlist`, `pairing`, or `open`. See [Group Chats](#group-chats)                                                                                                 |
+| `senderPolicy`      | No               | Deprecated: `allowlist`, `pairing`, or `open`; used only when `privatePolicy` is absent and DM access is enabled                                                                                            |
+| `dmPolicy`          | No               | Deprecated: `open` or `disabled`; used only when `privatePolicy` is absent                                                                                                                                  |
+| `operators`         | No               | Who may operate a shared session (`/approve`, `/clear`, `/loop`, ...). Unset or empty grants no shared-session operator permissions. See [Shared-Session Operators](#shared-session-operators)              |
+| `groupHistoryLimit` | No               | Opt-in group history backfill. `0` or omitted disables it. A positive number persists that many unmentioned group messages from senders admitted by the group member policy for the next bot mention/reply. |
+| `groups`            | No               | Per-group settings. Keys are group chat IDs or `"*"` for defaults. See [Group Chats](#group-chats)                                                                                                          |
+| `dispatchMode`      | No               | What happens when you send a message while the bot is busy: `steer` (default), `collect`, or `followup`. See [Dispatch Modes](#dispatch-modes)                                                              |
+
+### Message Routes
+
+Use `messageRoutes` to run multiple workflows through one Channel connection.
+Each key is a case-sensitive message prefix and each value contains instructions
+for that route:
+
+```json
+{
+  "messageRoutes": {
+    "/review": "Review the requested pull request.",
+    "/QA": "Answer questions about this repository."
+  },
+  "defaultMessageRoute": "/QA"
+}
+```
+
+A prefix must be followed by whitespace and a non-empty message. The longest
+matching prefix wins; leading mentions are skipped when matching. The matched prefix is removed before the
+message reaches the agent. Route instructions are combined with the Channel's
+common `instructions` on the first turn of each session. Routes use separate
+sessions within the configured `sessionScope`. Existing Channel memory remains
+shared at its configured chat/thread scope; routes are not a permissions sandbox.
+
+Without `defaultMessageRoute`, unmatched chat messages are ignored. To accept
+ordinary messages, set it to a key in `messageRoutes`; those messages keep their
+original text and use that route's instructions and session. Empty prefixes and
+empty route maps are invalid. Route instructions may be empty. Prefixes and
+instructions are trimmed when loading configuration. `messageRoutes` cannot be
+combined with `multiSession`.
+
+Routing does not grant access: private and group policies still apply. Shared
+and agent commands also need a route prefix, for example `/QA /help`. Messages
+without user-authored text and provider-generated system events remain outside
+prefix routing.
+
+### Private Policy
+
+`privatePolicy` controls private conversations independently of groups:
+
+- **`disabled`** — Ignore private messages without creating pairing requests.
+- **`allowlist`** — Only users listed in the top-level `allowedUsers` may send private messages.
+- **`pairing`** — Users in `allowedUsers` are admitted directly. Other users need a locally approved user pairing. See [DM Pairing](#dm-pairing).
+- **`open`** — Anyone can send private messages.
+
+New managed channels default to `pairing`. The deprecated `senderPolicy` and `dmPolicy` keys remain supported: an explicit `privatePolicy` takes precedence; otherwise `dmPolicy: "disabled"` disables private access, and otherwise `senderPolicy` supplies the policy (default `allowlist`). These old keys do not restrict group members. Saving from the editor uses `privatePolicy` and preserves existing deprecated keys.
+
+### Shared-Session Operators
+
+In a shared session (`sessionScope: "chat_thread"` or `"single"`, and group chats under `"thread"`), some commands affect everyone in the conversation: `/approve`, `/deny`, `/cancel`, `/clear`, `/who`, `/status`, `/loop`, `/btw`, the loop tool, and steering an in-flight turn. Only the session's operators may use them; other members' messages queue instead of steering. Sessions that are not shared belong to their own sender, who may always use them.
+
+Set `operators` to the user IDs allowed to manage shared sessions. Omitted or empty `operators` grants nobody this role. Private allowlists, user pairing, group pairing, and group member lists never imply operator permissions. Operators must still pass normal conversation admission.
+
+For example, `groups: { "*": { "senders": "open" } }` with `operators: ["alice"]` lets every admitted group member start a turn, but only Alice can manage its shared session.
+
+A saved loop is checked against the same rule when it fires, using its creator as the sender, and is disabled if the creator is no longer an operator.
 
 ### Session Scope
 
@@ -156,11 +205,12 @@ The legacy slash aliases `/remember-channel`, `/channel-memory`, and
 commands.
 
 Channel memory follows the channel access gates. Any message accepted by
-`senderPolicy`, `dmPolicy`, `groupPolicy`, group settings, pairing, and mention
-requirements can read, write, update, or clear memory for that chat or thread.
-Accepted members of the same group share that group's target store. Use
-`allowlist` or `pairing` policies when group memory should be limited to trusted
-senders.
+private access, group admission, group member settings,
+pairing, and mention requirements can read, write, update, or clear memory for
+that chat or thread. Accepted members of the same group share that group's
+target store. Use a group's `senders: "allowlist"` with its `allowedUsers` when group memory should be
+limited to trusted senders — under `senders: "open"` every member of an
+admitted group shares that group's memory store.
 
 Existing legacy `CHANNEL.md` memory is migrated automatically to structured
 `CHANNEL.json` storage on the first mutation. Structured memory persists across
@@ -194,7 +244,7 @@ Set the actual token in your shell environment or in a `.env` file that gets loa
 
 ## DM Pairing
 
-When `senderPolicy` is set to `"pairing"`, unknown senders go through an approval flow:
+When `privatePolicy` is set to `"pairing"`, unknown senders go through an approval flow:
 
 1. An unknown user sends a message to the bot
 2. The bot replies with an 8-character pairing code (e.g., `VEQDDWXJ`)
@@ -237,7 +287,7 @@ Controls whether the bot participates in group chats at all:
 
 - **`disabled`** (default) — The bot ignores all group messages. Safest option.
 - **`allowlist`** — The bot only responds in groups explicitly listed in `groups` by chat ID. The `"*"` key provides default settings but does **not** act as a wildcard allow.
-- **`pairing`** — A deliberate mention or reply from an unknown group creates one pairing request for the group. Once approved, every member can use the bot in that group; `senderPolicy` continues to control direct messages.
+- **`pairing`** — A deliberate mention or reply from an unknown group creates one pairing request for the group. Once approved, members can use the bot subject to the group's `senders` setting (default `open`); `privatePolicy` continues to control direct messages.
 - **`open`** — The bot responds in all groups it's added to. Use with caution.
 
 Approve a group with the same CLI command used for user pairing. The pending
@@ -276,6 +326,32 @@ Configure per-group with the `groups` setting:
 - **Group chat ID** — Override settings for a specific group. Overrides `"*"` defaults.
 - **`requireMention`** (default: `true`) — When `true`, the bot only responds to messages that @mention it or reply to one of its messages. When `false`, the bot responds to all messages (useful for dedicated task groups).
 
+### Group Senders
+
+Admitted groups allow all members by default. Set `senders` in `groups` to restrict members independently of private access:
+
+```json
+{
+  "privatePolicy": "pairing",
+  "groupPolicy": "open",
+  "groups": {
+    "*": { "senders": "open" },
+    "-100123456": { "senders": "allowlist", "allowedUsers": ["alice", "bob"] }
+  }
+}
+```
+
+- **`open`** (default) — Any member of an admitted group may use the bot. Private policy and user pairing have no effect on group members.
+- **`allowlist`** — only the group's `allowedUsers` may speak. This list is separate from the channel-level `allowedUsers`.
+
+All group settings use field-by-field inheritance: the specific group, then `"*"`, then the channel default where applicable, then the built-in default. Empty objects inherit defaults; arrays replace rather than merge, including `allowedUsers: []`. For example, a group that sets only `senders: "allowlist"` uses the `allowedUsers` from `"*"`. Under `groupPolicy: "allowlist"` a group ID key also admits the group, so a per-group entry there both admits the group and sets its senders.
+
+`pairing` is deliberately not a `senders` value: pairing approvals are stored per user, so approving someone through a group message would also unlock their direct messages. Use `groupPolicy: "pairing"` to admit an entire group instead.
+
+On the `github` and `gitlab` channels all inbound traffic is group traffic, so only `groupPolicy` and group member settings govern admission — see those channels' Security notes before using it on a public repository or project. Under `sessionScope: "single"` direct messages and groups share one conversation, so opening a group also exposes direct-message history to its members.
+
+In the Web Shell channel editor, **Who can talk in groups** and **Allowed group member IDs** edit `groups["*"]`, and **Session operators** edits `operators`. When `senders` is unset, the editor shows its effective default and writes nothing until you pick a value. Per-group overrides and an explicitly empty `"operators": []` are set in `settings.json`; saving from the editor keeps them.
+
 ### Group History Backfill
 
 By default, Qwen ignores unmentioned group messages and does not store them as session turns. To let the next `@mention` include recent group context, set `groupHistoryLimit` to a positive number.
@@ -303,7 +379,7 @@ By default, Qwen ignores unmentioned group messages and does not store them as s
 
 - Omitted or `0` disables backfill.
 - Group-level `groupHistoryLimit` overrides the channel-level value.
-- Only messages from authorized senders, or members of an approved paired group, are persisted.
+- Only messages from senders the group's `senders` setting admits are persisted (all admitted group members by default) — so `senders: "open"` also widens whose messages `groupHistoryLimit` records.
 - Messages rejected by `groupPolicy` or group allowlist are not persisted.
 - Pending group history is stored as local JSONL under `~/.qwen/channels/<channel-name>-group-history.jsonl` or `$QWEN_HOME/channels/<channel-name>-group-history.jsonl`.
 - Cached messages are injected as untrusted context on the next real trigger and are not written as standalone session turns.
@@ -312,10 +388,9 @@ By default, Qwen ignores unmentioned group messages and does not store them as s
 
 ```
 1. groupPolicy — is this group disabled, listed, paired, or open? (no → ignore/pairing flow)
-2. dmPolicy — is this DM allowed?                      (disabled → ignore)
-3. requireMention — was the bot mentioned/replied to? (no → ignore)
-4. senderPolicy — is this sender approved?             (skipped for a paired group; otherwise no → user pairing flow)
-5. Route to session
+2. requireMention — was the bot mentioned/replied to? (no → no task; eligible history may be cached)
+3. senders — is this member allowed?                  (open, or group member allowlist)
+4. Route to session
 ```
 
 ### Telegram Setup for Groups
@@ -531,7 +606,7 @@ qwen channel status --daemon-url http://127.0.0.1:4170 --token secret
 qwen channel stop --daemon-url http://127.0.0.1:4170 --token secret
 ```
 
-This mode starts workspace-grouped channel worker processes owned by `qwen serve`. Workers connect back to the daemon through the SDK and use the same channel adapters. They are separate from the daemon process, so a channel adapter crash does not crash the daemon. An explicit `--channel` selection takes precedence and fails daemon startup if it cannot become ready. On a flagless boot, every trusted registered workspace's own `serve.channels` setting is restored, and a name that cannot be hosted is skipped with a log instead of stopping the others. `all` remains primary-workspace only. Without either source, the daemon does not load channel adapters or reserve the lease until the first `qwen channel set`.
+This mode starts workspace-grouped channel worker processes owned by `qwen serve`. Workers connect back to the daemon through the SDK and use the same channel adapters. They are separate from the daemon process, so a channel adapter crash does not crash the daemon. An explicit `--channel` selection takes precedence and fails daemon startup if it cannot become ready. On a flagless boot, every trusted registered workspace's own `serve.channels` setting is restored, and a name that cannot be hosted is skipped with a log instead of stopping the others. `all` remains primary-workspace only. Registering a workspace later restores its channels too — without holding the registration open — once per daemon run, and not at all when the daemon was started with an explicit `--channel` or after `qwen channel stop`. Unlike the boot restore, one name it cannot host costs that workspace its whole list. Without any of these sources, the daemon does not load channel adapters or reserve the lease until the first `qwen channel set`, or until a workspace that configures its own `serve.channels` registers.
 
 Automatic restore skips invalid startup settings and validation or lease failures that occur before workers start, while preserving unrelated settings. After a worker startup fails, the daemon continues only once cleanup succeeds. A global runtime startup timeout or an unconfirmed worker stop still follows the normal startup-failure path; the service lease remains held while worker termination is unconfirmed. Check the daemon log for messages identifying `serve.channels` when a channel does not restore.
 
@@ -556,7 +631,7 @@ Example channel config:
       "clientId": "$DINGTALK_CLIENT_ID",
       "clientSecret": "$DINGTALK_CLIENT_SECRET",
       "cwd": "/repo",
-      "senderPolicy": "allowlist",
+      "privatePolicy": "allowlist",
       "allowedUsers": ["12345"],
       "approvalMode": "yolo",
       "sessionScope": "user",

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

@@ -35,7 +35,7 @@ Add a channel entry to `~/.qwen/settings.json` using the custom type provided by
     "my-bot": {
       "type": "my-platform",
       "apiKey": "$MY_PLATFORM_API_KEY",
-      "senderPolicy": "open",
+      "privatePolicy": "open",
       "cwd": "/path/to/project"
     }
   }
@@ -46,17 +46,17 @@ The `type` must match a channel type registered by an installed extension. Check
 
 All standard channel options work with custom channels:
 
-| Option         | Description                                                                                        |
-| -------------- | -------------------------------------------------------------------------------------------------- |
-| `senderPolicy` | `allowlist`, `pairing`, or `open`                                                                  |
-| `allowedUsers` | Static allowlist of sender IDs                                                                     |
-| `sessionScope` | `user`, `chat_thread`, or `single`; legacy `thread` remains compatible for existing configurations |
-| `cwd`          | Working directory for the agent                                                                    |
-| `instructions` | Prepended to the first message of each session                                                     |
-| `model`        | Model override for the channel                                                                     |
-| `groupPolicy`  | `disabled`, `allowlist`, `pairing`, or `open`                                                      |
-| `dmPolicy`     | `open` or `disabled`                                                                               |
-| `groups`       | Per-group settings                                                                                 |
+| Option          | Description                                                                                        |
+| --------------- | -------------------------------------------------------------------------------------------------- |
+| `privatePolicy` | `disabled`, `allowlist`, `pairing`, or `open`                                                      |
+| `allowedUsers`  | Private-message allowlist of user IDs                                                              |
+| `sessionScope`  | `user`, `chat_thread`, or `single`; legacy `thread` remains compatible for existing configurations |
+| `cwd`           | Working directory for the agent                                                                    |
+| `instructions`  | Prepended to the first message of each session                                                     |
+| `model`         | Model override for the channel                                                                     |
+| `groupPolicy`   | `disabled`, `allowlist`, `pairing`, or `open`                                                      |
+| `dmPolicy`      | Deprecated private fallback: `open` or `disabled`                                                  |
+| `groups`        | Per-group settings                                                                                 |
 
 See [Overview](./overview) for details on each option.
 

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

@@ -59,7 +59,7 @@ export QQ_APP_SECRET=<your-app-secret>
       "appID": "YOUR_APP_ID",
       "appSecret": "$QQ_APP_SECRET",
       "sandbox": false,
-      "senderPolicy": "open",
+      "privatePolicy": "open",
       "sessionScope": "user",
       "cwd": "/path/to/your/project",
       "instructions": "你是一个通过 QQ Bot 对话的 AI 助手。回复控制在 2000 字符以内。",
@@ -81,7 +81,7 @@ export QQ_APP_SECRET=<your-app-secret>
 | `sandbox`   | `false` | Set to `true` to use the QQ sandbox API environment (`sandbox.api.sgroup.qq.com`) |
 
 All standard channel options (see [Channel Overview](./overview#options)) are also supported:
-`senderPolicy`, `allowedUsers`, `sessionScope`, `cwd`, `instructions`, `groupPolicy`, `groups`, `dispatchMode`.
+`privatePolicy`, `allowedUsers`, `sessionScope`, `cwd`, `instructions`, `groupPolicy`, `groups`, `dispatchMode`.
 
 ## Running
 
@@ -102,7 +102,7 @@ To use the bot in QQ groups:
 1. Set `groupPolicy` to `"allowlist"`, `"pairing"`, or `"open"` in your channel config
 2. Add the bot to a QQ group via the QQ Bot Open Platform dashboard or by having a group admin invite it
 3. Group members must **@mention** the bot to trigger a response
-4. If using `groupPolicy: "pairing"`, approve the group's pairing request once before responses start. Note that once a group is approved, **any member of that group** can use the bot; `senderPolicy` and `allowedUsers` do not gate members of an approved group.
+4. If using `groupPolicy: "pairing"`, approve the group's pairing request once before responses start. Note that once a group is approved, **any member of that group** can use the bot by default (restrict with the group's `senders: "allowlist"` and `allowedUsers`); `privatePolicy` and the top-level `allowedUsers` do not gate members of an approved group.
 
 QQ Bot API V2 only delivers group messages that @mention the bot — the bot does not see all group messages. By default, `requireMention` is `true` and should be left that way for QQ.
 
@@ -135,7 +135,7 @@ Token refresh continues across WebSocket reconnects — the channel never goes o
 - **Use Markdown freely** — Unlike WeChat, QQ renders Markdown natively. Bold, code blocks, lists, and links all work.
 - **Keep responses under 2000 characters** — Longer responses are automatically split into chunks. Adding a length hint to your instructions helps the agent stay concise.
 - **Sandbox for testing** — Set `"sandbox": true` to use the sandbox API during development. No production messages will be affected.
-- **Restrict access** — Use `senderPolicy: "allowlist"` for a fixed set of QQ users, or `"pairing"` to approve new users from the CLI. See [DM Pairing](./overview#dm-pairing) for details.
+- **Restrict access** — Use `privatePolicy: "allowlist"` for a fixed set of QQ users, or `"pairing"` to approve new users from the CLI. See [DM Pairing](./overview#dm-pairing) for details.
 
 ## Key Differences from Telegram
 
@@ -154,7 +154,7 @@ Token refresh continues across WebSocket reconnects — the channel never goes o
 
 - Check the terminal output for errors
 - Verify the channel is running (`qwen channel status`)
-- If using `senderPolicy: "allowlist"`, make sure your QQ user ID is in `allowedUsers`
+- If using `privatePolicy: "allowlist"`, make sure your QQ user ID is in `allowedUsers`
 - On first start, a QR code will appear in the terminal — scan it with your QQ app
 
 ### Bot doesn't respond in groups

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

@@ -15,7 +15,7 @@ This guide covers setting up a Qwen Code channel on Telegram.
 
 ## Finding Your User ID
 
-To use `senderPolicy: "allowlist"` or `"pairing"`, you need your Telegram user ID (a numeric ID, not your username).
+To use `privatePolicy: "allowlist"` or `"pairing"`, you need your Telegram user ID (a numeric ID, not your username).
 
 The easiest way to find it:
 
@@ -32,7 +32,7 @@ Add the channel to `~/.qwen/settings.json`:
     "my-telegram": {
       "type": "telegram",
       "token": "$TELEGRAM_BOT_TOKEN",
-      "senderPolicy": "allowlist",
+      "privatePolicy": "allowlist",
       "allowedUsers": ["YOUR_USER_ID"],
       "sessionScope": "user",
       "cwd": "/path/to/your/project",
@@ -74,7 +74,7 @@ To use the bot in Telegram groups:
 2. **Disable privacy mode** in BotFather: `/mybots` → select your bot → Bot Settings → Group Privacy → Turn Off
 3. Add the bot to a group. If it was already in the group, **remove and re-add it** (Telegram caches privacy settings from when the bot joined)
 4. If using `groupPolicy: "allowlist"`, add the group's chat ID to `groups` in your config
-5. If using `groupPolicy: "pairing"`, approve the group's pairing request once before responses start. Note that once a group is approved, **any member of that group** can use the bot; `senderPolicy` and `allowedUsers` do not gate members of an approved group.
+5. If using `groupPolicy: "pairing"`, approve the group's pairing request once before responses start. Note that once a group is approved, **any member of that group** can use the bot by default (restrict with the group's `senders: "allowlist"` and `allowedUsers`); `privatePolicy` and the top-level `allowedUsers` do not gate members of an approved group.
 
 By default, the bot requires an @mention or a reply to respond in groups. Set `"requireMention": false` for a specific group to make it respond to all messages (useful for dedicated task groups). See [Group Chats](./overview#group-chats) for full details.
 
@@ -90,7 +90,7 @@ You can send photos and documents to the bot, not just text.
 
 - **Keep instructions concise-focused** — Telegram has a 4096-character message limit. Adding instructions like "keep responses short" helps the agent stay within bounds.
 - **Use `sessionScope: "user"`** — This gives each user their own conversation. Use `/clear` to start fresh.
-- **Restrict access** — Use `senderPolicy: "allowlist"` for a fixed set of users, or `"pairing"` to let new users request access with a code you approve via CLI. See [DM Pairing](./overview#dm-pairing) for details.
+- **Restrict access** — Use `privatePolicy: "allowlist"` for a fixed set of users, or `"pairing"` to let new users request access with a code you approve via CLI. See [DM Pairing](./overview#dm-pairing) for details.
 
 ## Message Formatting
 
@@ -101,7 +101,7 @@ The agent's markdown responses are automatically converted to Telegram-compatibl
 ### Bot doesn't respond
 
 - Check that the bot token is correct and the environment variable is set
-- Verify your user ID is in `allowedUsers` if using `senderPolicy: "allowlist"`, or that you've been approved if using `"pairing"`
+- Verify your user ID is in `allowedUsers` if using `privatePolicy: "allowlist"`, or that you've been approved if using `"pairing"`
 - Check the terminal output for errors
 
 ### Bot doesn't respond in groups

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

@@ -34,7 +34,7 @@ Add the channel to `~/.qwen/settings.json`:
       "type": "wecom",
       "botId": "$WECOM_BOT_ID",
       "secret": "$WECOM_SECRET",
-      "senderPolicy": "allowlist",
+      "privatePolicy": "allowlist",
       "allowedUsers": ["zhangsan"],
       "sessionScope": "user",
       "cwd": "/path/to/your/project",
@@ -73,13 +73,14 @@ Open WeCom and send a message to the intelligent robot.
 
 ## Access Control
 
-`senderPolicy` works the same way as other IM channels:
+`privatePolicy` works the same way as other IM channels:
 
-- `allowlist`: only users in `allowedUsers` can use the bot. This is the recommended enterprise default.
+- `disabled`: ignore all private messages without creating pairing requests.
+- `allowlist`: only users in the top-level `allowedUsers` can send private messages. This is the recommended enterprise default.
 - `pairing`: users must pair before using the bot.
 - `open`: anyone who can message the robot can use it.
 
-For groups, set `groupPolicy` to `"allowlist"`, `"pairing"`, or `"open"`. Under `"pairing"`, the group's first mention creates a pairing request that must be approved once before responses start. Note that under `groupPolicy: "pairing"`, access is granted per group: once a group is approved, **any member of that group** can use the bot; `senderPolicy` and `allowedUsers` do not gate members of an approved group. WeCom only delivers group messages that mention the intelligent robot, so every delivered group callback is treated as mentioned. The `requireMention` setting cannot enable responses to unmentioned group messages because those messages are not delivered to the bot.
+For groups, set `groupPolicy` to `"allowlist"`, `"pairing"`, or `"open"`. Under `"pairing"`, the group's first mention creates a pairing request that must be approved once before responses start. Note that under `groupPolicy: "pairing"`, access is granted per group: once a group is approved, **any member of that group** can use the bot by default (restrict with the group's `senders: "allowlist"` and `allowedUsers`); `privatePolicy` and the top-level `allowedUsers` do not gate members of an approved group. WeCom only delivers group messages that mention the intelligent robot, so every delivered group callback is treated as mentioned. The `requireMention` setting cannot enable responses to unmentioned group messages because those messages are not delivered to the bot.
 
 ### Group Mention Compatibility