[Bug]: /goal verifier aborts the whole run on a single denied web_fetch/web_search call (paused(verifier_capability)) #419

Activity

1. Hylouis233 commented on Oct 1, 2026

   

   Hylouis233

   on Oct 1, 2026

   Author

   More actions

   The fix branch is pushed: Hylouis233:work (commit 69810ab).

   git fetch https://github.com/Hylouis233/minimax-code.git work
   git diff main...work
   

   It contains:

   • goal-subagent-coordinator.ts — bounded recovery window before latching capability_violation
   • goal-verifier-reminder.ts — states the run is offline and routes an evidence gap to PARTIAL
   • goal-verifier-readonly-guard.test.ts — 6 new cases, registered in test/vitest-suites.json

   The two central cases were confirmed to fail against the unpatched coordinator (2 failed | 4 passed) and pass with the fix, so they pin the behaviour change rather than the shape of the new code. Also green: 145 goal-suite tests, tsc -p tsconfig.standalone.json --noEmit, and eslint on all touched files.

   I could not open a PR directly (the account lacks createPullRequest on this repo), so the branch is on the fork for a maintainer to pull from, or I can transfer it wherever preferred.
2. hetaoBackend commented on Oct 1, 2026

   

   hetaoBackend

   on Oct 1, 2026

   Collaborator

   More actions

   This was generated by AI during triage.

   @Hylouis233 — I verified every step of this chain against main, and it's correct line for line. This is a real bug with a real fix already in progress on your side.

   Verification (against main)

   In packages/local-runtime-v2/src/application/agent/goal-subagent-coordinator.ts:

   • :17 — GOAL_VERIFIER_DENIED_TOOLS = new Set(['web_fetch', 'web_search']) — exactly the two tools you name, and they are the only ones that reach this guard.
   • :162-167 — beforeTool blocks the call and latches the issue:

     if (!GOAL_VERIFIER_DENIED_TOOLS.has(toolName)) return undefined;
     // Latched, not aborted here: the blocked result goes back to the model and
     // the next `beforeLlm` stops the run on the latched issue.
     this.latchIssue(state, { code: 'capability_violation', message: reason });
     return { block: true, reason };

   • :113 — the next beforeLlm turns any latched issue into an abort: if (state.issue) return { type: 'abort', reason: state.issue.message };

   So your central observation is exact: the comment describes a recovery path that is never reachable, because the child is stopped before it gets the turn in which it could act on the rejection. And your two reachability arguments check out too — the reminder (goal-verifier-reminder.ts) describes the read-only boundary in detail but never states that the two network tools are unavailable, and the verifier role's five-tool grant minus the read-only ceiling leaves web_fetch/web_search as precisely the calls that can trip this.

   Assessment

   Your diagnosis of why this is a defect rather than intended behavior is the part I agree with most: FAILURE_REASONS.capability_violation → paused(verifier_capability) is the right framing for a genuine catalog defect, but a model reaching for web_search once on a local-workspace objective is a recoverable detour, not a catalog defect. Pausing the whole Goal on it surfaces to the user as an unexplained failure, which is the real harm.

   Your proposed fix shape — a bounded recovery window (N≈2) where the first denials block without latching, and only a repeat offender latches capability_violation — is a proportionate fix: it preserves the guard's intent for the genuine loop case, and route_unavailable / child_budget_exhausted stay untouched with maxTurns/maxTokens still bounding the outer loop. The independent reminder clause (offline run + "evidence gap → PARTIAL, don't reach for the network") is a good complement because it stops the common case from spending a turn on a denied call at all.

   I also like that your test cases were confirmed to fail against the unpatched coordinator (2 failed | 4 passed) and pass with the fix — that pins the behavior change rather than the shape of the new code, which is the right way to review it.

   Classification

   • Category: bug — a single denied tool call aborts the run; the user gets a hard error instead of a verdict.
   • State: needs-triage — root cause confirmed, fix prepared and locally verified. It needs a maintainer to bring the commit in with attribution. (This tracker has no ready-for-human label, so needs-triage + this note is the routing.)

   Process

   As you note, you can't open a PR directly, so use the same path as #149 / #364 / #391: the branch is the deliverable — just post the commit link here (or ping a maintainer) so it can be landed with attribution. When you do, please make sure the new test file is registered in test/vitest-suites.json (you noted you did — good, that's the gate that actually runs it) and re-run the full applicable pnpm verify against current main, since a few toolchain/test issues have landed since (test:sandbox and test:byok in particular were both fixed this week).

   Strong report — the fact that you quoted the latching comment back at us as evidence that the documented recovery is unreachable is exactly the right way to make the case.

   No credentials or sensitive data echoed.
3. hetaoBackend

   added

   bugSomething isn't workingSomething isn't working

   needs-triageAwaiting maintainer assessmentAwaiting maintainer assessment

   on Oct 1, 2026