Coding agents redefine unclear permission answers as denials

Gemini CLI's September 26 nightly closes a gap in what happens when a permission prompt can't reach a person. Non-interactive ASK_USER decisions now resolve to DENY on every safety path, per gemini-cli's permission-resolution fix. The same update wraps MCP resources and web-search output as untrusted context instead of trusted input.

The stakes are concrete: a silent timeout or a malformed config line used to mean a tool ran unchecked. Now three separate agents treat that ambiguity as a reason to stop, not go.

Qwen Code found a sharper version of the same problem. A bug let a later allow rule override an earlier deny rule on the same hook matcher, so the tool ran when it should have been blocked. Qwen Code's hook permission fix reranks the decisions most-restrictive-wins: if any hook says deny, deny wins regardless of order.

Claude Code 2.1.283 closes a related gap. An invalid nested value anywhere in a managed sandbox config block used to get the whole block discarded, stripping out restrictions that had nothing wrong with them. A bad line no longer takes the rest of the policy down with it.

Three agents, three different bugs, one rule: a missing answer or a broken config line is not permission. That's a real shift from the failure mode these systems shipped with.

If you're running multiple hook scripts against one matcher in any of these agents, test the disagreement case. Point one hook at allow and another at deny on the same action and confirm deny wins. Qwen Code's bug shows that assumption doesn't hold by default, it has to be built and verified.