Qwen Code v0.27.3修复自动编辑模式绕过用户强制询问规则的问题，并补齐Shell特定覆盖重定向的写入识别。命中询问规则的后台子代理和非交互任务将拒绝相关调用，普通未受保护操作不受此变化影响。此次修复仍有Shell解析缺口，不代表权限绕过风险已全面解决。
QwenLM于2026年11月13日发布Qwen Code v0.27.3，修复两类影响编程智能体授权边界的问题：自动编辑模式不再直接批准命中用户强制询问规则的工具调用，Shell命令分析器也补上了对特定覆盖重定向写入的识别。
对依赖后台子代理或非交互任务的团队，这次更新可能带来一个容易误判的变化：某些此前能够自动完成的调用，升级后会被拒绝。按照实现说明，原因不是工具失去相应能力，而是用户原先设置的权限规则开始在这些路径上得到执行。不过，修复范围有限，开发者仍列出了其他Shell解析缺口，不能据此认定所有权限绕过问题均已解决。
官方发布API记录，该版本首次公开于11月13日00:24:34 UTC，标记为非草稿、非预发布。审批规则修复和重定向识别修复分别于11月11日、12日合并；11月13日的新进展，是它们进入v0.27.3发布，而不是这些问题当天才首次被发现。
自动编辑，不等于忽略用户的“先问我”
PR #16932的说明指出，旧有auto-edit快捷路径会自动批准确认类型为编辑或信息提示的调用。即使用户通过permissions.ask要求访问特定路径前先询问，相关编辑、读取或搜索也可能在没有提示的情况下执行。
这不仅影响主动选择自动编辑模式的人。作者解释，在受信任文件夹中，如果主会话使用默认的询问权限模式，而子代理定义没有指定自己的审批模式，子代理可能以auto-edit运行。于是，同一个受保护路径，主会话访问时会询问，交给子代理后却可能不再询问。主会话的界面状态，并不足以说明委派出去的调用走了相同审批路径。
修复同时涉及CLI工具调度器与ACP会话。后者承载IDE集成以及包括Web Shell在内的相关会话。新增条件会识别调用是否因为命中用户ask规则而必须询问，而不是把所有默认需要确认的工具都一概拦下。
这一区分保留了auto-edit的原有用途：没有命中用户ask规则的普通编辑，仍可自动批准。变化针对的是用户明确设置的例外，而不是取消自动编辑模式。
无法询问的任务，会怎样处理？
按照同一PR披露的行为，命中用户ask规则后，交互式主会话会进入正常确认提示，且不会提供“始终允许”选项；前台子代理则在Agent调用下方显示内联审批。后台子代理无法弹出询问，会拒绝相应调用；非交互运行同样拒绝，而不是自动执行。
因此，“升级后新增拒绝”有明确前提：调用命中了用户的ask规则。不能将它概括为所有后台任务停止运行，也不能说所有读取、搜索或编辑都必须改成人工操作。作者披露的后台测试中，受规则保护的搜索被拒绝，同批其他未受保护的搜索仍然执行。
这也解释了为什么发布说明可以写“没有已知破坏性变更”，实现说明却仍提醒自动化用户注意行为变化：设置格式和API没有改变，但过去依赖auto-edit越过自身ask规则的流程，不再得到同样结果。
对部署者而言，需要检查的是哪些调用必须经过人工判断、它们是否被安排在无法交互的任务中。如果决定给某个调用预先授权，应把这当作一次权限调整，而不是为了恢复任务运行就普遍取消保护。此次修复没有改变YOLO模式，不能将其描述为所有审批模式都新增了相同限制。
写入保护的前提，是分析器能看见写入
PR #17042处理的是另一层问题：用户已经禁止写入某个文件，但命令分析器没有正确识别Shell实际执行的写操作。
在Bash中，>|是一种强制覆盖重定向，即使启用防止覆盖文件的noclobber选项，也可以写入已有文件。旧分析器却会把其中的竖线误当成管道分隔符，导致权限判定看不到写入目标。这样，针对该路径设置的Write(...)拒绝规则便可能不生效。
修复同时调整了复合命令切分与重定向识别，将>|、1>|和2>|识别为相应文件写入，并覆盖目标前有无空格的情况。它还补齐了特定引号或转义字符紧贴重定向时的识别。真正的管道、被引号包住的字面字符以及文件描述符复制，则需要保留各自不同的语义。
这不是新增一套拒绝规则，而是让已有规则能够匹配它本来就要约束的操作。过去看起来只是普通输出的命令，修复后可能因实际涉及受保护文件写入而被拒绝或要求确认。
不过，作者明确列出尚未处理的情况，包括跨行续接的重定向、部分反斜杠组合、here-string与重定向相连，以及某些引号词紧贴重定向的写法。其中，跨行续接的写入即使能被单命令分析器识别，仍可能在权限判定使用的复合切分路径中丢失。修补一种语法识别，不能等同于完成整个Shell权限模型的安全审计。
从提醒人审批，到真正执行审批规则
本站此前关于v0.27.2的报道讨论了渠道配置进入Web Shell，以及等待人工审批时的状态展示与通知。v0.27.3这两项修复的重点不同：前者解决人能否及时注意到审批请求，本次则涉及应当询问的调用是否真的进入审批，以及应当禁止的写入能否被识别。
这一区别也是理解编程智能体安全性的关键。提示更醒目、后台调度更方便，与权限规则被正确执行，是不同层面的能力；即使规则被执行，也仍要确认分析器对实际操作的理解是否准确。
验证证据同样需要限定。审批修复作者披露了CLI行为对照和单元测试，但说明ACP路径只有单元测试覆盖，未通过真实IDE或Web Shell会话实测。重定向修复作者披露了Bash行为核对及权限测试，同时保留了未覆盖范围。这些属于实现方提供的验证，不是独立安全审计；本报道未安装软件或复现相关问题。
此外，v0.27.3主发布不是预发布，并不意味着所有新增内部机制都已默认启用。完整变更说明中，部分统一智能体循环改动仍以实验设置为前提。对现有部署，更实际的升级检查是：受保护路径在主会话、前台和后台子代理中是否得到预期处理，无人值守任务能否明确报告权限拒绝，以及Shell写入保护是否覆盖自身使用的命令形态，而不是仅凭版本号推断系统已经全面安全。