docs(approval-mode): count destructive blocks in the loop-guard bullet

`docs/users/features/approval-mode.md` described the AUTO mode loop guard as "three consecutive policy blocks" after which "the next call" falls back. Since the destructive-command escalation, deterministic destructive-command blocks also count towards that cap, and `shouldFallback` is evaluated on the post-increment state, so the call that reaches the third block falls back on that same call. Mirrors the wording already delivered for the sibling bullet in `docs/users/features/auto-mode.md`, keeping the two user docs consistent. Co-authored-by: Qwen-Coder <[email protected]> Patrol-Run: qwen-pr-closeout/jmuzbyw3ref
yiliang114 · Oct 10, 2026 · Oct 8, 2026 · Oct 8, 2026 · Oct 8, 2026 · Oct 8, 2026
commit 43fef6f2b6a94db97e5fd70e0fbfc1c16c643fb0
diff --git a/docs/users/features/approval-mode.md b/docs/users/features/approval-mode.md
@@ -269,9 +269,10 @@ settings.json. See [auto-mode.md](./auto-mode.md#configuring-hints).
 - **Fail-closed**: when the classifier API is unreachable, the action is
   blocked rather than allowed. After two consecutive unavailable calls,
   the next tool call falls back to manual approval.
-- **Loop guard**: after three consecutive policy blocks, the next call
-  also falls back to manual approval so the agent isn't stuck cycling on
-  a dead-end approach.
+- **Loop guard**: after three consecutive blocks — classifier policy blocks
+  and deterministic destructive-command blocks both count — the call that
+  reaches the third block also falls back to manual approval so the agent
+  isn't stuck cycling on a dead-end approach.
 
 ### Example