You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Agent loops 277 times on MCP resource_list without circuit breaker #31942
An OpenCode agent made 277 consecutive calls to gumps_mcp_resource_list searching for a non-existent MCP resource, exhausting the workspace token spend limit. No built-in circuit breaker or loop detection prevented this.
Steps to Reproduce
Configure an OpenCode agent with an MCP server (MCP Gateway at https://mcp-dev.gumps.net/mcp)
Ask the agent to find or use an MCP resource/skill that does not exist on that server (e.g., "m365-inbox")
Observe the agent repeatedly calling mcp_resource_list with different filter prefixes
Expected Behavior
After 2–3 consecutive mcp_resource_list calls returning no matching results, the agent should stop searching and report that the resource was not found.
Actual Behavior
The agent called gumps_mcp_resource_list 277 times in a single session, each time with a slightly different filter prefix, all returning empty results. This consumed enough tokens to hit the $500 workspace spend limit, blocking all further agent activity.
The agent did not recognize the pattern of repeated empty results and did not stop.
Acceptance Criteria
Agent detects repeated identical-tool calls with empty/no-match results and stops after a configurable threshold (e.g., 3 consecutive misses)
Agent reports "resource not found" to the user instead of continuing to search
A built-in circuit breaker prevents any single tool from being called more than N times consecutively with the same outcome
Regression test added covering repeated empty MCP resource searches
Additional Context
Environment: Production (gumps-daily-flash repo, OpenCode runtime)
Frequency: Observed once, but the pattern is deterministic — any search for a non-existent resource triggers it
Business impact: Hit $500 workspace spend limit, blocked all agent activity until limit reset
Evidence: Changelog entry in gumps-daily-flash repo: [2026-06-11 10:00] NOTE Agent looped 277 times calling gumps_mcp_resource_list searching for non-existent "m365-inbox" skills
Workaround applied: Created a project-level .cursor/rules/loop-prevention.mdc rule instructing agents to stop after 3 consecutive empty results. This is a belt-and-sunders fix at the project level; the platform should enforce this natively.
User-supplied hypothesis (unverified): This is a bug in OpenCode's loop detection — the platform should have a built-in circuit breaker for repeated tool calls.
Filed by AI Agent | Platform: opencode | Repo: newgumps/it-director
Ref: IT-DIR-f81560f4 | 2026-06-11 | Context: Agent spent $500 workspace limit on 277 MCP resource_list calls
This issue might be a duplicate of existing issues. Please check:
Infinite retry loop when provider returns zero output at context limit (finish=unknown) #31757: Describes a very similar infinite retry loop with no circuit breaker — same core problem (agent loops indefinitely on a repeated pattern), same proposed fix (detect N consecutive identical outcomes and abort). The fix suggested there (post-response guard for zero-output + unknown finish) is closely related to what this issue requests (circuit breaker for repeated empty tool results).
If your issue is distinct from those (e.g. specific to MCP tool call repetition rather than LLM finish-reason handling), please clarify how it differs.
I think the important distinction here is that this is not just an "agent got confused" bug, it's an economic-boundary bug.
Once the runtime sees the same tool family producing the same outcome fingerprint repeatedly (in this case: resource_list -> empty/no-match -> reformulated prefix -> empty/no-match), that should stop counting as exploration and start counting as failed state transition.
A few controls that would have helped a lot here:
track tool + normalized intent + outcome fingerprint, not just raw tool count
break after N consecutive no-delta outcomes, even if the query string changes slightly
record last_meaningful_delta_at so the runtime can tell the difference between real progress and search churn
enforce a per-tool economic cap before the workspace-level spend cap gets touched
emit a typed stop reason like resource_search_exhausted or circuit_breaker_repeated_empty_result
The part that stands out to me is the 277-call stretch. By that point the system has already proven it doesn't know something new; it's just burning budget while preserving the illusion of activity.
We've been caring about exactly this false-progress / runaway-spend class in MartinLoop, so I was glad to see this written up this concretely. If you're open to it, I'd genuinely value your feedback on whether the right abstraction here is "loop detection" or something stricter like "economic stop conditions around repeated no-delta agent behavior."
Activity
github-actions commentedon Jun 11, 2026
This issue might be a duplicate of existing issues. Please check:
If your issue is distinct from those (e.g. specific to MCP tool call repetition rather than LLM finish-reason handling), please clarify how it differs.
Keesan12 commentedon Jul 9, 2026
I think the important distinction here is that this is not just an "agent got confused" bug, it's an economic-boundary bug.
Once the runtime sees the same tool family producing the same outcome fingerprint repeatedly (in this case:
resource_list-> empty/no-match -> reformulated prefix -> empty/no-match), that should stop counting as exploration and start counting as failed state transition.A few controls that would have helped a lot here:
tool + normalized intent + outcome fingerprint, not just raw tool countlast_meaningful_delta_atso the runtime can tell the difference between real progress and search churnresource_search_exhaustedorcircuit_breaker_repeated_empty_resultThe part that stands out to me is the 277-call stretch. By that point the system has already proven it doesn't know something new; it's just burning budget while preserving the illusion of activity.
We've been caring about exactly this false-progress / runaway-spend class in MartinLoop, so I was glad to see this written up this concretely. If you're open to it, I'd genuinely value your feedback on whether the right abstraction here is "loop detection" or something stricter like "economic stop conditions around repeated no-delta agent behavior."
github-actions commentedon Sep 7, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.