Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#419 2 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

  • #467 par @amszuidas — fermée sans fusion

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
72/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
typescript
Domaine
ai, devtools

Piste de recherche

Read packages/local-runtime-v2/src/application/agent/goal-subagent-coordinator.ts, focusing on GoalVerifierChildCoordinator.beforeTool and beforeLlm, then inspect goal-verifier-reminder.ts. Verify the denied-call regression behavior: initial network denials allow recovery without aborting, repeated denials still pause the verifier, and the reminder states that the run is offline and missing evidence can be PARTIAL.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

bug needs-triage

Summary

In /goal mode, a Goal verifier child that calls web_fetch or web_search once has its entire run aborted, and the user gets a hard error instead of a verdict:

GOAL_VERIFIER_CAPABILITY_VIOLATION: readonly Goal verification blocked tool "web_fetch".
# → 出了点小问题，请稍后重试

The Goal settles as paused(verifier_capability).

The objective of a Goal is always about the local workspace, and the child still holds read, grep and bash, so a single denied network call has a straightforward local answer. Stopping the run for it leaves the user with no way forward.

Root cause

GoalVerifierChildCoordinator.beforeTool blocks the call and latches a capability_violation issue. The next beforeLlm converts any latched issue into an abort:

// beforeTool — the latch happens here
this.latchIssue(state, { code: 'capability_violation', message: reason });
return { block: true, reason };

// beforeLlm — and the run dies on the very next turn
if (state.issue) return { type: 'abort', reason: state.issue.message };

beforeTool's own comment states "the blocked result goes back to the model and the next beforeLlm stops the run on the latched issue" — the recovery is described but never reachable. The child cannot act on the rejection, because it is stopped before it gets a turn in which to do so.

Two things make this reachable in practice:

  1. renderGoalVerifierReminder describes the read-only boundary in detail but never says the two network tools are unavailable. The model has no way to know in advance.
  2. web_fetch/web_search are precisely the two tools that survive the verifier role's five-tool grant minus the canonical read-only ceiling, so they are the only calls that ever reach this guard.

Suggested direction

Count denied calls per run and allow a bounded number of them to be spent on recovery:

  • First N denials (N≈2): still block: true, but the reason states the run is offline and names the local alternative, and no issue is latched — the child continues and can reach the same evidence.
  • Past N: the child is looping rather than detouring; latch capability_violation as today.

route_unavailable and child_budget_exhausted would be untouched, and maxTurns/maxTokens stay as the outer bound on a child that keeps retrying.

Independently, adding one clause to the reminder — that the run is offline and that a missing-evidence situation is a PARTIAL rather than a reason to reach for the network — would stop the common case from spending a turn on a denied call at all.

On the current design intent

FAILURE_REASONS.capability_violation → paused(verifier_capability) is documented as owned by the readonly guard / tool catalog layer. That framing is right for a genuine catalog defect, but a model reaching for web_search once on a local objective is not one, and pausing the whole Goal surfaces as an unexplained failure to the user. Keeping the latch for the repeat case preserves the intent; it only stops firing on a single recoverable mistake.

Environment

  • App: MiniMax Code 3.0.74-inside.104 (macOS, arm64)
  • Reproduced on the released build; the same code path is in packages/local-runtime-v2/src/application/agent/goal-subagent-coordinator.ts and goal-verifier-reminder.ts

A fix with tests and a verified fail-before/pass-after regression is ready in a fork branch (Hylouis233:work) — happy to open a PR if that is preferred over a maintainer-side patch.

Langage dominant
TypeScript
Étoiles
2.1k
Forks
271
Merge moyen
14 h 23 min
PR mergées (30 j)
35

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de MiniMax-AI/minimax-code

Toutes les issues de MiniMax-AI/minimax-code

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.