QwenLM 发布 Qwen Code v0.26.7，收紧编程智能体对仓库可执行配置的默认信任，要求对部分钩子、语言服务器和权限授予进行显式目录或工作区信任。版本保留设置文件中非交互钩子的例外，并提出后续取消该豁免的修复提案；同时为本地 /verify-pr 提供基于宿主代理的 Docker 密钥转发配方以减少凭据暴露风险。
QwenLM 于2026年11月4日发布 Qwen Code v0.26.7，将编程智能体处理仓库配置时的信任边界进一步收紧：项目提供的部分钩子命令、权限授予和语言服务器，不再因为目录信任功能处于关闭状态就被默认放行。不过，这并不是“打开任何仓库都已安全”的保证，尤其是无人值守运行仍有明确例外。
官方发布说明将这些改动列为工具链修复，而非新的基础模型发布。GitHub 发布记录显示，该版本首次公开于11月4日04:03:01 UTC，标记为非草稿、非预发布。理解这次更新，关键不在于模型是否更会写代码，而在于仓库中的哪些内容可以变成真正执行的程序，以及由谁批准。
阅读项目说明，不等于允许项目执行命令
编程智能体接触的仓库不只有源代码，也可能包含技能说明、子智能体定义和工具配置。其中，文字指令可以提供任务背景；钩子（hooks）则能在特定事件发生时运行命令，项目语言服务器也需要启动可执行程序。两者的风险并不相同：允许模型阅读一份说明，不应自动等于允许其中附带的程序在本机运行。
PR #16182针对的正是这一区别。开发者解释，原有判断会在目录信任功能关闭时把所有目录视为受信任，使仓库提供的部分可执行配置无需明确授信便能生效。新规则要求仓库提供的 skill 与 subagent 钩子、skill 权限授予，以及项目语言服务器，获得显式目录信任，或由集成开发环境（IDE）明确授予工作区信任。
检查也不只发生在首次读取配置时。项目钩子和权限在使用时重新核对信任，语言服务器则在可执行文件探测或启动前检查，覆盖重新加载和重启。开发者同时说明，YOLO 模式不豁免这一要求；没有获得相应执行授权时，技能和智能体的文字说明仍可使用。
对依赖这些配置的用户，变化可能表现为升级后某些钩子或服务器不再启动。该 PR 给出的迁移方式，是在用户设置中启用 security.folderTrust.enabled，再通过既有授信流程批准目录；CLI 信任变更后需要重启。这是为已审查的项目恢复能力的方法，而不是应对陌生仓库一律授信的理由。
修复范围也有边界。开发者明确把项目外部 agent executor 的独立执行路径排除在该 PR 之外，没有声称所有仓库提供的可执行入口均已受到同样保护。用户配置、内置配置和扩展配置也保留各自既有策略，不能把项目配置的新规则泛化到所有来源。
设置文件钩子的非交互例外仍然存在
另一项容易被混淆的变化，针对仓库 .qwen/settings.json 中声明的项目钩子。PR #16196要求交互式会话取得显式目录或工作区信任；未授信时，终端界面会显示项目钩子未加载的启动警告。
但该改动保留了非交互例外：使用 --prompt、-p、管道标准输入，或通过 ACP/SDK 嵌入运行时，仍将调用方选择工作目录视为隐式信任，项目设置文件中的钩子可照常加载。这里的例外针对设置文件项目钩子，不能反过来理解为所有技能钩子或语言服务器都获得非交互豁免。
开发者保留这一行为的理由，是兼容没有交互审批界面的嵌入平台，避免已有部署需要迁移信任文件。实际代价是：如果自动化系统把陌生仓库直接作为工作目录，升级到 v0.26.7 本身并不能替代对仓库配置的审查。“调用方选定目录”和“目录内容已经可信”仍是两回事。
这一边界已有后续修复提案。PR #16264提出取消非交互豁免，让设置文件项目钩子在交互、无头运行和 ACP/SDK 嵌入中统一要求显式授信。作者称，外部安全报告中的一次性无头调用场景，在第一轮修复保留的豁免下仍能复现。该提案在本文核验时仍处于开放、未合并状态，不能写成 v0.26.7 已交付的保护措施。
因此，对无人值守平台更稳妥的判断是：需要按实际运行模式确认钩子加载规则，审查工作目录和项目配置，并将后续补丁是否合并、是否进入部署版本分开核对。版本发布、PR 提案和实际部署，不是同一个状态。
把真实模型密钥留在宿主机
v0.26.7 还为本地 /verify-pr 增加 Docker 操作配方，处理另一类信任问题：维护者验证外部贡献的代码时，如何避免把真实模型 API 密钥一并交给待验证环境。
根据PR #16077，新方案由宿主机代理持有真实密钥，只转发聊天补全请求。容器使用单次运行的令牌访问代理，代理再在上游请求中换入真实密钥。这样，运行不可信 PR 代码的容器无需直接持有真实模型凭据。
这个设计将“可以调用指定代理”与“持有真实密钥”分开，但并不意味着容器内代码已经安全。配方要求代理脚本和相关验证材料来自可信检出，而非待审查 PR 的代码；否则，持有真实密钥的宿主机反而可能执行外部贡献者改写的脚本。凭据留在宿主机，只有在宿主机运行的程序本身可信时才有意义。
验证范围同样需要保留限定。作者披露，本地 Linux Docker 冒烟测试覆盖代理转发、凭据扫描、隔离门禁等环节，使用的是模拟上游；没有在容器内使用真实模型完成整轮 /verify-pr 验证。此次改动也没有修改既有 CI 通道。它是一套更具体的维护者操作方案，而不是对任意 PR、所有容器隔离或全部 CI 流程的安全背书。
PR 事件可回到原会话，但不会默认替用户公开回复
安全修复之外，版本还补充了持续跟进代码审查的工作流。PR #16117允许 GitHub 事件进入与相应 PR 绑定的既有会话，使创建、审查或验证该 PR 的智能体能够利用原有上下文，而非总是把事件交给另一段通道会话。
事件提示会把 GitHub 内容标记为不可信数据，并沿用群组、发送者和配对等预检查。绑定会话的回复保留在会话内，不会自动发布到 GitHub。这一点区分了“把外部事件交给模型分析”和“授权模型对外发言”，也不应被解释为外部评论因此变成可信指令。
配套的可选状态监测可以观察 CI 失败、合并冲突、提交更新以及合并或关闭等变化。开发者称，检测在 API 层进行，出现实际状态转换后才触发模型处理；持续轮询仍会产生 API 请求，不能称为零成本。控制这些能力的 deliverToBoundSessions 与 prWatchEvents 默认均不启用，已有部署不会仅因升级就自动接管所有 PR 事件。
这与此前Qwen Code v0.26.5 为反复失败的 PR 检查设置重试预算形成了不同层面的补充：前者约束自动修复何时交由人工，当前版本则改善事件送达哪个会话，以及回复是否对外公开。本次更重要的新增边界，是仓库配置获得执行能力前的显式信任要求。
升级之后，仍要看运行方式和证据范围
这些改动共同说明，编程智能体的安全不只是模型能否拒绝恶意提示，也取决于运行系统如何区分文字与程序、项目配置与用户授权、会话回复与公开发布。
现有测试证据主要来自开发者披露，不能当作本站独立复测。显式信任修复的本地端到端测试使用 macOS 和模拟模型，并未覆盖真实 IDE 连接、完整语言服务器协议初始化及 Windows、Linux 本地执行等全部场景；Docker 配方的验证也不等于真实模型下的完整审查流程。
对使用者而言，v0.26.7 值得关注的是若干具体执行路径不再默认放行，而不是一项笼统的“智能体已经安全”承诺。尤其在非交互部署中，设置文件项目钩子的现行例外与尚未合并的统一授信提案必须分清。只有把运行模式、配置来源、凭据边界和已发布补丁逐一对应，才能判断升级究竟改变了什么。