Agent thrashing: identical bash/read tools succeed with ~4 tok and never stop

Summary

In long agent sessions, jcode allows the model to call the same (or nearly identical) tools over and over—especially read and bash—while each call is marked ✓ success but returns only ~4 tokens of payload. The agent never progresses to a user-facing answer; the UI stays on tool rows and “sending context” for a long time.

This looks like a combination of weak model tool-use strategy and missing harness safeguards (loop detection / empty-result handling). Filing as a robustness request: the harness should stop or escalate thrashing instead of burning tokens indefinitely.

Environment

Item	Value
jcode	0.68.0
OS	macOS (Apple Silicon)
Install	Official installer (~/.local/bin/jcode)
Model	grok-4.5
Reasoning effort	high
Provider	OpenAI-compatible custom profile (third-party gateway)
UI	Interactive TUI

Symptoms

1. Agent enters a long streak of nearly identical tool calls, e.g.:
   • read with prompts like “Read the full raw content” / “Dump the full file…” repeatedly on the same path
   • bash with the same git fsck ... filter/hash repeated many times
2. Each call shows green ✓, but reported size is often ~4 tok (far too small for a real file read or useful command output).
3. Session does not produce a final assistant reply for a long time; context keep growing (sending context).
4. User must interrupt manually (Esc / stop generation).

Reproduction (observed, not 100% deterministic)

Not a one-click minimal repro every time, but reliably appears under multi-step Executor / verify workflows:

Case A – after background command

1. Agent finishes an edit and offers to run pnpm build.
2. User: “you run it” / similar.
3. jcode starts a Background task for pnpm build.
4. UI shows something like: bg pnpm build completed · exit 0 · ~1s and “No output captured.”
5. Agent tries to cat the bg output file → bash exit 1.
6. Agent then loops on read of the same source file with ~4 tok each time.

Case B – preflight / status check

1. System/user prompt: Executor role; load AGENTS.md + handoff contract; verify current state and report back; wait for user confirmation before coding.
2. Agent correctly reads the handoff doc once (thousands of tokens—OK).
3. Then starts heavy git archaeology (git cat-file, git fsck, blob greps).
4. One bash fails (exit 1).
5. Agent then repeats nearly the same git fsck ... -v '<blob>' (or equivalent) many times, each ✓ ~4 tok, and never stops to summarize for the user.

Screenshots available on request (tool list with dozens of identical ✓ rows).

Expected behavior

• If the same tool + highly similar arguments run N times (e.g. ≥5) with empty/near-empty results, harness should:
  • stop the loop, or
  • inject a system nudge: “tool returned no useful output; change strategy or ask the user”, or
  • force a short user-facing summary and pause.
• Empty / tiny tool payloads should not look like full success in a way that encourages blind retry (or should be labeled as low-signal / failed for agent purposes).
• Background tasks that complete with “No output captured” should surface a clearer error path so the agent doesn’t thrash on missing output files.

Actual behavior

• No effective circuit breaker; identical or near-identical tools continue indefinitely.
• ~4-token results still show as successful tool invocations.
• Token burn and long stalls; user must interrupt.

Impact

• High token cost on paid gateways.
• Broken UX for multi-step / Executor handoff flows.
• More common with mid-tier models (e.g. grok-4.5 high), but harness should protect users regardless of model quality.

Notes / partial workarounds

• Manually interrupt + hard instruction: “Stop all git fsck/read loops. Summarize in ≤5 lines and wait.”
• Stronger models thrash less often, but empty tool results still shouldn’t allow unbounded loops.
• Separate issue observed earlier: some gateways reject reasoning_effort: "max" for grok-4.5 (only low|medium|high); not the same bug, but same session stack (OpenAI-compatible + grok-4.5 high).

Request

Please consider:

1. Tool-loop detection (same tool + similar args / same target path, N times).
2. Treat empty / sub-threshold tool output as a soft failure for the agent (and maybe UI warning).
3. Better background task output capture / explicit “no log file” status so agents don’t spin on missing outputs.

Happy to provide more logs (session id, redacted tool traces) if useful.

Checklist

• jcode version: 0.68.0
• Model: grok-4.5, effort high
• Repro context described (Executor handoff + bg build)
• Expected vs actual
• Minimal single-command repro (hard; thrashing is multi-turn)—can try to isolate further if needed

The issue names no files, tests, or entry points. Start by tracing tool-call execution, result handling, and background-task output capture, then determine how repeated similar calls and tiny results are represented. Done means a reproducible safeguard stops or escalates thrashing and missing background output no longer encourages unbounded retries.