[core] No early termination on repeated tool errors: sessions burn 5-14M tokens in dead-end loops #10887

Current main verification — 2026-10-07

Verified at main base 464f486e2019 through the actual foreground daemon/ACP Session, real native git subprocesses, provider wire and tmux capture. With the guard environment genuinely unset, nine distinct git calls all fail with exit 128 and typed execution_status=error, error_type=shell_execute_error. The actual decisions are tracked → would_warn → would_stop in shadow mode. The ninth result still reaches the main continuation; there is no corrective reminder or guard stop. The controlled provider then ends the turn naturally.

This upgrades the earlier helper observation to native Session evidence. It does not reproduce the historical long-running deployment or its token expenditure. Requests are attributed from their actual prompts: four main, one managed-memory and one suggestion side query.

The existing rollout contract requires version-pinned, owner-assigned cohort activation before enforce; the initial automatic routes remain off. Do not treat the presence of the detector or an enforce-mode substitution as a default-path fix. Keep this issue open pending the affected deployment version, guard mode, ACP host/cohort and original traces, including Stop/todo continuation ownership. The separate #13321 reminder enhancement does not change this failure-guard policy.

Original report

What happened?

Production sessions on versions 0.20.1–0.21.0 exhibit a pattern where the agent enters a dead-end exploration loop — tools repeatedly return the same error (e.g. git remote -v exit 128, permission denied) — but no mechanism terminates the loop. Sessions consume 5–14M tokens over 49–138 rounds before being externally truncated or exhausting the budget.

Observed cases (anonymized labels; original session identifiers omitted):

Expected behavior

When tools repeatedly return the same error class (e.g. same exit code, same permission denial), the agent should:

1. Detect the repetition (e.g. 3–5 consecutive identical errors)
2. Terminate the current exploration path
3. Report the failure reason to the user
4. Optionally try an alternative approach if one exists

Current behavior

The existing loop detection (packages/core/src/core/loopDetection.ts) focuses on detecting repeated tool call sequences but does not trigger on repeated tool error results. The agent keeps retrying the same failing operation indefinitely.

Suggested fix

1. Tool-error repetition detection: track consecutive tool results with identical error signatures (exit code + error message hash). After N consecutive matches (configurable, default 3), inject a system message forcing the agent to stop that path.
2. Per-session token budget hard cap: enforce a maximum total token consumption per session (e.g. 2M tokens). When exceeded, force-terminate with a user-facing summary of what was accomplished and what failed.

Environment

• qwen-code versions: 0.20.1-dataworks.0, 0.21.0-dataworks.0
• Model: qwen3.7-max / qwen3.8-max