Qwen Code 0.22安全更新要点

Qwen Code 0.22 工具面与自动权限清单

最初发表于 IndieSeek。

Qwen Code v0.22.0 将一个内置工具默认设为更安全，并将一种审批模式变得更易于从 SDK 触达。list_directory 现为可选加入：除非你启用 tools.listDirectory.enabled 或在 coreTools 中明确包含它，否则不会注册或发送给模型。Python 和 Java SDK 的启动选项现在接受 auto，与 CLI 和 TypeScript SDK 保持一致。在该模式下，LLM 分类器会评估每次工具调用，自动批准它判定为安全的操作，同时阻止有风险的操作。

这些改动并不意味着 auto 是最小权限策略。Qwen 有三层不同的控制层：注册了哪些工具、哪些调用跳过确认、以及已批准的调用可以在哪里执行。将它们分开对待，检查实际的工具面，并在无害的负面探针通过之前保持默认审批。

本指南适用于通过 CLI、Python、Java 或 TypeScript SDK 嵌入 Qwen Code 并寻找 --yolo 的安全替代方案的团队。在本地 OpenAI 兼容后端、自定义 Agent、MCP 服务器或无人值守的仓库作业场景下尤为有用，因为额外的工具 schema 和模糊的审批容易造成真实的操作风险。

如果仓库本身可能不可信，请将此次发布与 Qwen 工作区信任清单配合使用。工作区信任决定哪些项目配置可以加载；本文决定运行中的 Agent 可以看到哪些工具以及如何批准它们的调用。

0.22 发生了什么——以及没发生什么

这个区分很重要，因为稳定的 TypeScript SDK 文档将 coreTools 描述为注册白名单，而 allowedTools 和 permissions.allow 则对匹配的调用跳过确认。Qwen 稳定的 permission-manager 测试也表明，MCP、Skill、Agent 和若干合成工具与内置 coreTools 面是分开的。因此，简短的内置工具列表是一个有用的缩减，而不是完整会话只有这些能力的证明。

使用三层权限矩阵

永远不要用某一行的证据来认证另一行。隐藏的工具可能仍可通过 MCP 触达。可见的工具仍可能需要审批。自动批准的调用仍可能受限于主机运行时——或者危险地不受约束。

六步发布流程

1. 固定确切的执行文件

运行 /about 并记录报告的 Qwen Code 版本、在可用时记录 commit、运行时、模型/提供商、审批模式、沙箱状态和工作区。本指南在稳定标签 v0.22.0、commit 1c3a385d9bc83e0b2a1ce5a24454ce1d090595fb 下检查。不要使用每日构建来声称稳定行为。

2. 从小型注册内核开始

使用一个临时仓库和默认审批。一个探针会话可以这样启动：

qwen --approval-mode default --core-tools read_file,grep_search,glob

确认 /tools 不显示 list_directory、编辑或 shell 执行。然后故意请求目录列表并验证 Qwen 使用 glob 或报告 list_directory 不可用。如果工作流确实需要旧工具，明确启用它并重复清点；不要仅仅为了消除提示就恢复它。

3. 验证出站 schema，而不只是 UI

一个针对精确 0.22.0 的公开 issue 报告了一种情况：某设置下 /tools 看起来减少了，但本地 OpenAI 兼容后端仍收到完整的内置工具数组。这是一份用户报告，不是普遍结论，但它提供了一个有价值的探针：通过录制代理或提供商调试日志仅捕获出站工具名称，并与 /tools 比较。删除参数、提示词、凭据、路径和文件内容。

如果两份清单不一致，保持交互模式。不要将设置文件或更小的 UI 列表作为充分证明。

4. 单独测试审批

保持注册工具集固定，用无害调用比较 default 和 auto：

读取临时工作区内的一个已知 fixture 文件。

请求写入一个临时文件并记录该调用是询问、批准还是阻止。

请求一个明显超出范围的邻近操作，但不要使用真实密钥或破坏性命令。

为该邻近操作添加一条明确的拒绝规则并证明它仍然被拒绝。

auto 是分类器决策，因此要求审计记录显示 decision_source=classifier。不要将其重写为策略批准或人工批准。

5. 运行七个探针

list_directory 默认不存在。

明确的 opt-in 恢复它，重启使变更可观察。

coreTools 中省略的内置工具对会话不可用。

出站工具名称清单与预期的注册面一致。

default 对临时写操作进行提示。

auto 记录其分类器决策而不会悄然变成 yolo。

同样的被拒绝邻近操作在两种模式下都保持被拒绝。

对于 MCP、Skill 和自定义 Agent，添加单独的清单和拒绝测试。它们不会自动被内置内核探针认证。当允许的调用可以改变外部状态时，使用 MCP 安全回放清单。

6. 按操作类别晋升

从只读仓库探索开始。在回滚和 diff 审查工作之后才添加有边界的编辑。将 shell、网络写入、发布、计费、部署、密钥和破坏性文件系统操作保持在明确人工审批或确定性策略上。沙箱会减少后果；但它不会让分类器成为消费金钱、发布内容或破坏状态的权威。

该工具对这个任务来说是必需的吗？
  否 -> 不注册它
  是 -> 它的范围还能进一步缩小吗？
           是 -> 缩小 core/MCP 注册并重新清点

该调用是否改变状态或跨越信任边界？
  是 -> 明确人工或确定性审批
  否 -> 运行无害的 default 模式探针
          schema、决策和约束证据是否一致？
            否 -> 保持交互模式并修复边界
            是 -> 考虑有边界的 auto 模式试点

常见错误

将 permissions.allow 作为未列出 schema 从未发送的证明。

称 auto 为"安全模式"或确定性白名单。

假设 coreTools 覆盖了 MCP、Skill、自定义 Agent 和所有合成工具。

因为旧 prompt 提到了 list_directory 就启用它，而不检查 glob 是否已经完成了该任务。

使用真实凭据、生产仓库或破坏性命令进行测试。

称 Qwen 的 Autofix digest 绑定为每个用户沙箱的保证。

只记录最终工具结果，丢失版本、注册面、匹配的规则和决策来源。

可复制验收记录

qwen_version / commit / install_channel / runtime:
workspace / provider / model / sandbox:
registered_core_tools / mcp_tools / skill_tools / agent_tools:
outbound_tool_names_match_inventory: yes | no | not-observable
approval_mode / permission_rules / sdk_callback:
canary / tool / redacted_scope / expected / actual:
decision_source: human | deterministic-rule | classifier | none
containment_result / denied_neighbor / rollback_result:
promotion: hold | read-only | bounded-edit | human-required

auto 比 yolo 更安全吗？

它更有选择性：auto 使用 LLM 分类器，而 yolo 自动批准所有工具调用。但有选择性并不意味着确定性，也不意味着对高影响力操作已经足够。对敏感的状态变更保持明确审批。

为什么 list_directory 被禁用而 Qwen 仍能检查文件？

发布说明称 glob 在大多数情况下覆盖了目录列表，因此移除这个近似重复的工具可以减少 prompt 和选择面。它不是通用的文件系统访问开关；其他读取工具仍然存在。

我应该用 permissions.allow 还是 coreTools 来缩小 schema？

对于稳定的 v0.22.0，将 coreTools 视为内置注册白名单，将 permissions.allow 视为调用自动批准。然后验证实际的出站工具名称。不要仅依赖命名或迁移文本。

Qwen Code 稳定版 v0.22.0 发布

Qwen Code PR #9424：使 list_directory 变为可选加入

Qwen Code PR #9003：Python 和 Java SDK 支持 auto

Qwen Code v0.22.0 TypeScript SDK 权限文档

Qwen Code v0.22.0 设置参考

Qwen Code issue #9827：精确版本 schema 面报告

Qwen Code PR #9527：Autofix 沙箱镜像 digest 绑定

在 IndieSeek 阅读维护版本。