QwenLM 发布 Qwen Code v0.26.8，引入项目钩子（hooks）的交互式审批并修复无头/非交互运行中的隐式信任例外，强化仓库配置在无人值守与嵌入场景下的执行授权边界。更新还扩展了 CLI、VS Code 和桌面端的订阅接入，但文档提示部分表述仍需对照以确保迁移与授权流程无歧义。
QwenLM于2026年11月5日发布Qwen Code v0.26.8，将项目钩子（hooks）的审批机制和取消非交互隐式信任的修复纳入正式版本。对把编程智能体接入持续集成、无人值守任务或嵌入式平台的团队而言，关键变化不是模型写代码能力，而是仓库中的配置能否在没有明确授权的情况下变成实际执行的命令。
官方发布记录显示，该版本首次公开于当日16:23:57 UTC，为非草稿、非预发布版本。更新同时加入CLI、VS Code和桌面端的Qwen订阅登录，但安全改动尤其值得单独理解：此前“由调用方选定工作目录”所代表的隐式信任，不再足以让设置文件中的项目钩子自动运行。
不过，两项修复同时进入版本，并不意味着每一种运行模式都必须依次通过“目录授信”和“钩子审批”两道相同关卡。版本文档允许不同授权路径，部分段落的描述也尚未完全一致；把它概括成所有仓库执行入口均已安全，会超出证据范围。
从打开仓库，到允许仓库执行程序
钩子是在会话开始、工具调用前后等事件发生时执行的程序或其他处理逻辑。它们可以用于审计、检查和工作流集成，但命令型钩子也会以用户权限运行。仓库提供的.qwen/settings.json因此不只是偏好设置，还可能携带可执行行为。
项目钩子审批PR #14748解释了原有风险：目录信任功能默认关闭时，项目设置可以被完整载入，仓库作者写入的会话启动钩子可能在用户启动工具时运行，而不先征求同意。开发者将其描述为攻击者诱导用户克隆仓库后可利用的代码执行问题；这份说明并未提供现实攻击规模或受害者统计。
此次新增的交互式审批界面会展示钩子的事件、匹配条件、命令及相关配置，让用户决定批准、拒绝或暂缓。决定保存在用户本地的~/.qwen/hookApprovals.json，并绑定所审阅配置的哈希，而不是给仓库未来所有修改永久放行。
v0.26.8的钩子文档进一步说明，审批还绑定工作区自身的.env文件和settings.env。钩子或这些相关值发生变化时，需要重新决定；已经拒绝且没有变化的配置不会反复弹出询问。这里的保护对象不仅是命令文本，也包括可能影响命令实际行为的环境配置。
无人值守运行不再自带信任豁免
另一项进入发布记录的PR #16264，针对的是上一轮修复留下的非交互例外。作者称，外部报告中的一次性无头调用仍能在全新默认环境执行仓库钩子，因为旧规则把这类运行排除在显式信任要求之外。
该修复取消这一豁免，覆盖交互终端、无头任务及ACP/SDK嵌入场景。其核心意义是：自动化系统选中了一个工作目录，不再自动等于已审查并授权其中的项目钩子。在既无配置审批、也无明确信任决定的全新默认环境中，版本文档明确表示仓库钩子不会执行。
这一变化承接了本站此前对v0.26.7权限边界的报道。旧版本保留设置文件钩子的非交互例外，当时#16264还只是未合并提案；v0.26.8的新增事实，是取消例外和审批机制均已列入正式发布记录，而不是把上一版的保护措施重新介绍一遍。
对依赖仓库钩子的自动化部署，行为改变可能表现为升级后钩子停止加载。#16264要求嵌入平台在其管理的用户环境中配置可信目录；版本钩子文档则同时列出记录配置审批或启用目录信任并预先授信的路径。无论采用哪种方式，授权都应来自用户或平台管理的环境，而不是由待处理仓库自行宣布可信。
审批与目录信任，不能拼成一张绝对权限表
两项PR分别描述自己的修复目标，但理解最终版本仍要对照随标签发布的文档。钩子文档的概述和安全模型写明：设置文件项目钩子可凭“对精确配置的审批”或“显式目录信任”取得执行授权；配置已经获批时，即使目录信任功能关闭，也可以运行。显式目录信任包括启用security.folderTrust.enabled后授信目录，或由IDE授予工作区信任。
这与“所有模式必须同时完成目录授信和逐项钩子审批”并不是一回事。反过来，如果目录信任功能已经启用而目录仍不可信，工作区设置根本不会载入，审批对话框也无法凭空出现。
文档仍有需要保留的边界：审批章节一方面说明交互会话可回退到显式目录信任，另一方面又称非交互运行中未审批的项目钩子不会加载；概述和安全模型则将非交互运行也纳入上述二选一规则。对于“目录已授信、配置尚未审批”的非交互组合，这些表述并不完全一致，不能据此宣称已获得一张没有例外的完整权限矩阵。
YOLO模式也不是统一的万能绕过开关。审批章节区分了从命令行明确要求YOLO与仓库设置中的YOLO值：后者不能自行跳过审批，因为设置本身可能由仓库控制。文档还区分交互和非交互YOLO行为，不能将“命令行可跳过审批提示”扩大为所有运行方式都能绕过目录信任保护。
此外，项目技能或子智能体前置元数据中的钩子，不在此次设置文件钩子的审批范围内，仍要求显式目录或IDE工作区信任。用户级和系统级钩子也不应被混入仓库钩子的变更范围。
迁移成本与安全保证，都需要限定
正式发布页的“Breaking Changes”栏目写着“没有已知破坏性变更”，但#16264明确把仓库钩子默认行为的改变标为破坏性变更，并提醒无头用户和嵌入平台迁移。这两种表述需要同时看：发布页的概括，不能抵消实现说明中对既有自动化可能停载钩子的警告。
可信目录文档也提醒，目录信任功能依然默认关闭，其他项目配置仍可能运行命令，例如命令型状态栏。项目钩子新增审批，并不等于读取任意仓库配置都已经没有执行风险；批准一段钩子，也不等于验证了整个仓库。
开发者在相关PR中披露了本地验证和测试通过情况，但这些是实现方提供的证据，不是独立安全审计。审批PR还列出未覆盖范围，包括实验性LSP命令路径，以及会话中批准后不会补发已经错过的会话启动事件。此次更新应被理解为修补具体执行路径，而不是对所有平台、所有配置和所有攻击方式作出保证。
订阅接入扩展到三端，但不等于全链路验证完成
安全修复之外，版本还纳入Qwen订阅接入PR #16378。CLI、VS Code和桌面端共用设备授权、凭证刷新及会员校验流程，为符合条件的账号加载模型目录，并使用订阅进行对话和内置网页搜索；已有API Key提供方仍可使用。
这项功能进入发布记录，与所有原生客户端和购买链路均已验证完成，仍是两个不同判断。该PR明确表示，本次修订的原生客户端及购买流程仍需端到端验证，因此不能从代码合并推导出所有账号、系统和订阅场景都已经得到实测确认。
v0.26.8更实质的变化，是进一步把“仓库提供了什么”与“用户授权执行什么”分开。对开发者和平台运营者，升级后的重点不是简单取消警告，而是辨明配置来源、授权路径和实际运行模式，避免为了恢复自动化而重新给予陌生仓库过宽的信任。