hermes - 💡(How to fix) Fix Bug: Agent enters retry loop when execute_code output is truncated / empty

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Error Message

empty due to an internal error, the agent interprets the partial/empty Tool layer: Return a structured error when output is truncated, making

Fix Action

Fix / Workaround

Problem

When execute_code tool output is truncated (50 KB cap hit) or returns empty due to an internal error, the agent interprets the partial/empty result as a transient failure and retries the same code in the next turn — leading to a loop of 2–4 identical execute_code calls before it gives up or the user interrupts.

Observed Behavior

  1. Agent calls execute_code with a script that produces large stdout
  2. Platform layer truncates output (50 KB cap) or tool returns empty result
  3. Agent receives output that looks like "no output" or partial output
  4. Agent re-issues the same execute_code call, reasoning the previous attempt "didn't complete"
  5. Steps 2–4 repeat 2–4 times

Why This Is Hard to Fix in a Single Place

This is agent reasoning behavior, not a deterministic tool bug. The retry decision happens in the LLM turn, not in the tool itself. Possible mitigations at different layers: Tool layer: Return a structured error when output is truncated, making it unambiguous that the call did run but output was cut: {"status": "truncated", "bytes_captured": N, "exit_code": 0} Currently truncation is silent from the agent's perspective. Prompt layer: Instruct the agent that a missing/empty execute_code result means output was dropped, not that execution failed — not a retry signal. Gateway layer: Detect consecutive identical execute_code calls and inject a warning before the next LLM turn.

Reproduction

Reliably reproduced by running execute_code with a script that prints more than ~50 KB of stdout. The agent sees empty output and retries.

Notes

Not filing a PR — the correct fix depends on which layer(s) upstream wants to address. Filing this to document the phenomenon and start the discussion.

RAW_BUFFERClick to expand / collapse

Problem

When execute_code tool output is truncated (50 KB cap hit) or returns empty due to an internal error, the agent interprets the partial/empty result as a transient failure and retries the same code in the next turn — leading to a loop of 2–4 identical execute_code calls before it gives up or the user interrupts.

Observed Behavior

  1. Agent calls execute_code with a script that produces large stdout
  2. Platform layer truncates output (50 KB cap) or tool returns empty result
  3. Agent receives output that looks like "no output" or partial output
  4. Agent re-issues the same execute_code call, reasoning the previous attempt "didn't complete"
  5. Steps 2–4 repeat 2–4 times

Why This Is Hard to Fix in a Single Place

This is agent reasoning behavior, not a deterministic tool bug. The retry decision happens in the LLM turn, not in the tool itself. Possible mitigations at different layers: Tool layer: Return a structured error when output is truncated, making it unambiguous that the call did run but output was cut: {"status": "truncated", "bytes_captured": N, "exit_code": 0} Currently truncation is silent from the agent's perspective. Prompt layer: Instruct the agent that a missing/empty execute_code result means output was dropped, not that execution failed — not a retry signal. Gateway layer: Detect consecutive identical execute_code calls and inject a warning before the next LLM turn.

Reproduction

Reliably reproduced by running execute_code with a script that prints more than ~50 KB of stdout. The agent sees empty output and retries.

Notes

Not filing a PR — the correct fix depends on which layer(s) upstream wants to address. Filing this to document the phenomenon and start the discussion.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

hermes - 💡(How to fix) Fix Bug: Agent enters retry loop when execute_code output is truncated / empty