openclaw - 💡(How to fix) Fix [Bug]: session_status tool-call loop not hard-aborted — agent repeats 30+ identical calls despite loop detector warnings [1 comments, 2 participants]

Environment

• OpenClaw: 2026.4.26 (be8c246)
• OS: Linux 6.8.0-107-generic (x64)
• Node: v22.22.1
• Model: claude-opus-4.6 (via custom provider)
• Session type: human-facing agent:main:main (Telegram direct)

Bug summary

When the agent calls session_status as part of assembling a status dashboard, it enters an infinite loop — calling session_status with identical (empty) arguments 30+ times. The built-in loop detector fires warnings at 10/20/30 but never hard-aborts the agent run. The session gets stuck until manual intervention.

This has happened at least twice on our instance (April 21 and April 29, 2026), both times triggered by a user request to display a status panel, which causes the agent to call session_status as part of data gathering.

Steps to reproduce

1. Run a long-lived agent:main:main session with moderate context usage (~47%)
2. User asks the agent to show a status dashboard
3. Agent calls session_status with {} to gather session metadata
4. Agent enters a degenerate loop — repeats the same session_status call indefinitely
5. Loop detector warns at N=10, N=20, N=30 but does not stop the agent

Expected behavior

The agent run should be hard-aborted after a configurable threshold (e.g. 5 identical tool calls), not just warned.

Actual behavior

• Loop detector prints warnings in tool results
• Agent ignores warnings and continues calling
• Session is stuck, blocking the queue (queueDepth=1)
• Burns API tokens on identical calls
• Requires manual gateway restart or session kill to recover

Workaround

Using openclaw status --json and openclaw cron list --json via the exec tool instead of calling session_status directly. This bypasses the tool-call loop entirely.

Related issues

• #58726 — "Loop detector should hard-abort agent after N identical tool calls, not just warn" (OPEN, same root cause, requests configurable hard-abort threshold)
• #71615 — "tool-heavy main sessions can jump from low context to near-full within 1-2 replay turns" (CLOSED in 2026.4.26, related context pressure that may increase loop likelihood)
• #40144 — "scope tool-loop detection history to the active run" (fixed in 2026.4.26, scoping fix only, not hard-abort)
• #34574 — "ignore volatile exec metadata when comparing tool-loop outcomes" (fixed in 2026.4.26, exec-specific)

Notes

The 2026.4.26 release includes two loop-detection improvements (#40144, #34574), but neither adds a hard-abort mechanism. The loop detector remains advisory-only — it warns but never force-stops the agent. This is the same gap described in #58726.

A hard-abort at N>5 identical calls (configurable, default 5) would prevent this class of stuck sessions entirely.