Summary

• Problem: Issue Bug: loopDetection cannot block message tool loops — volatile messageId in result defeats all critical-level detection paths #89090 reports that loopDetection detects repeated message.send calls (ping_pong, warning level) but can never escalate to a block. A model stuck in a tool-call loop keeps sending duplicate messages — 30+ duplicates reported — until runRetries.max (default 160) is exhausted; the user only sees a flood of identical messages and the warning the model ignores.
• Root Cause: In tool-loop-detection.ts, hashToolOutcome hashes the full result for the send tools. A successful send returns through jsonResult(payload), so the per-call delivery ids land in both the result details (e.g. messageId, receipt, the gateway runId) and the result text (the stringified payload). The hash therefore differs on every call. All three critical-block paths — the global circuit breaker, ping_pong critical, and generic no-progress — require consecutive identical resultHash values (getNoProgressStreak / noProgressEvidence), which is structurally impossible for a tool whose result carries a unique id. Detection fires only at warning level because it also keys on argsHash, which is stable.
• Fix: Hash a stable, id-stripped projection of the result, scoped to delivery results only — sessions_send and the outbound-message actions (send, broadcast, reply, thread-reply, sendWithEffect, sendAttachment, upload-file, sticker, poll) of the multi-action message tool.
  • isVolatileSendResult gates the path: sessions_send and the outbound-message actions above on the multi-action message tool get the stripped hash, while message's mutate/query actions (read, search, edit, react, unsend, list-pins, thread-list, …) keep full-result hashing because their ids/timestamps are real progress. Provider-docked send tools (channel plugins registered as named tools, e.g. telegram/discord) return the same volatile-id shape and are matched via the shared isMessagingToolSendAction detector, so loops on them escalate too; SEND_LIKE_MESSAGE_ACTIONS stays intentionally broader than that helper's terminal-send set (broadcast/reply/sticker/poll are volatile but not terminal sends).
  • stripVolatileSendIds recursively removes VOLATILE_SEND_RESULT_KEYS (messageId, message_id, messageIds, platformMessageId, platformMessageIds, fileId, fileKey, pollId, receipt, runId, idempotencyKey, ts, timestamp, sentAt, deliveredAt, createdAt) from details at any depth — so it also neutralizes the nested ids in a broadcast payload (results[].result.messageId).
  • It also drops a message object's own bare id (detected via isMessageDeliveryObject: a string id + text plus conversation/direction/senderId/accountId) so plugin-shaped delivery results normalize too, while a stable nested route/conversation.id is preserved.
  • The stringified text is not hashed for delivery results (it is the payload restated and carries the same volatile ids); the stable delivery facts (ok / status / channel / target) remain.
  • The loop detector's own veto result (buildBlockedToolResult with deniedReason: "tool-loop") gets no result hash, so a critical block stays sticky instead of the block resetting the streak. Other blocked results (plugin/approval vetoes) keep their hash, so repeated identical denials still escalate normally.
  • This runs at the shared hashToolOutcome layer, so it covers the message tool, sessions_send, and provider-docked channel tools uniformly (direct, gateway, and plugin-handled send results). Repeated identical-args sends now produce a stable resultHash, so the no-progress / critical paths fire and the loop is blocked.
  • Why this is safe (no false positives): no-progress requires BOTH argsHash and resultHash to repeat. The args hash already carries the message content and target, so two genuinely different messages have different argsHash and are never flagged — dropping the volatile ids only restores detection for true same-args resends.
• What changed:
  • src/agents/tool-loop-detection.ts — add SEND_LIKE_MESSAGE_ACTIONS, VOLATILE_SEND_RESULT_KEYS, stripVolatileSendIds, isVolatileSendResult, isMessageDeliveryObject, and isLoopVetoResult; branch delivery results to the id-stripped hash inside hashToolOutcome and give blocked/veto results no hash. isVolatileSendResult delegates provider-docked tool names to the shared isMessagingToolSendAction (from embedded-agent-messaging.ts), unifying the send-action source of truth; the denylist also covers platformMessageId/platformMessageIds.
  • src/agents/tool-loop-detection.test.ts — fifteen regression cases on the real jsonResult result shape (stable hash across ids in details+text, nested broadcast ids, escalation to critical for message send, sibling reply and upload-file (fresh file id) actions, sessions_send, and a provider-docked telegram send, no false-positive on distinct messages, a non-send message read whose id/timestamp progress must stay distinct, a stable nested route id that must survive the strip, and a critical block that stays sticky after the veto result is recorded).
• What did NOT change (scope boundary):
  • Generic / exec / process / poll detector semantics, non-send message action hashing, thresholds, and retry caps are untouched — nothing was loosened or raised; this restores the existing block behavior for delivery results only.
  • No config surface (no schema, defaults, doctor migrations, or docs/reference/config).
  • No plugin surface (no plugin SDK, manifest, extensions/* api/runtime-api, registry/loader).
  • Gateway protocol unchanged.

Reproduction

1. Configure an agent with a model prone to tool-call loops on a channel that returns a per-send message id (e.g. Feishu).
2. The model loops on message.send with identical arguments.
3. Before this PR: ping_pong fires at warning level but never reaches critical/block; the user receives 30+ duplicate messages until run-retries are exhausted.
4. After this PR: the repeated identical send is recognized as no-progress and escalates to a critical block.

Deterministic source reproduction (added as regression tests): record repeated sends with identical args but changing delivery ids in the result, then call detectToolCallLoop — before the fix it can never reach a critical branch.

Real behavior proof

Behavior addressed (#89090 — send loops can now be blocked, not just warned): repeated identical message.send (and sessions_send) escalates to a critical block instead of spamming until run-retry exhaustion.

Real environment tested (Linux, Node — Vitest against the production loop-detection module using the real jsonResult result shape; no live channel run): verified via tool-loop-detection.test.ts, plus core production type-check and a scoped test type-check over the two changed files, plus format check. A live multi-channel gateway loop was not run.

Exact steps or command run after this patch (repo-root): node scripts/run-vitest.mjs src/agents/tool-loop-detection.test.ts; node scripts/run-tsgo.mjs -p tsconfig.core.json (core types) and a scoped tsgo over the changed production + test files (test types); oxfmt --check on the changed files.

Evidence after fix (Vitest output for the touched test file):

 tool-loop-detection.test.ts   Tests  58 passed (58)

Fifteen new cases pass, all built on the real jsonResult result shape (volatile id present in both details and the stringified text): a stable result hash across two sends whose ids differ; stable hash across broadcast results with per-call nested ids; escalation to critical for message send, reply, upload-file, sessions_send, and a provider-docked telegram send despite every id differing; a plugin-shaped result whose message object carries a bare per-send id; no stuck result when the sends carry distinct content (different args); a non-send message read whose results differ only by id/timestamp staying distinct (full hashing preserved); a stable nested route id that survives the strip; a changing conversation.id that stays below critical; and a critical block that stays sticky after the veto result is recorded.

Observed result after fix (identical-args send loops reach critical/block): detectToolCallLoop reports stuck at critical for repeated identical sends, while distinct-content sends remain unflagged.

What was not tested (live channel/gateway runaway loop): a real Feishu/gateway loop session was not reproduced live; the proof is the deterministic module-level reproduction the issue itself describes.

Repro confirmation: with the production delivery branch removed on an otherwise-identical tree, the four send behavior cases fail (stable-hash, nested-broadcast, and both escalation cases); and when the branch is instead broadened to every message action (dropping the params.action gate), the non-send read case fails — so both the fix and its action-scoping are covered by tests that fail on the shape the runtime actually produces rather than passing vacuously. All cases pass with the scoped fix.

Risk / Mitigation

• Risk: over-stripping result fields could collide distinct outcomes. Mitigation: only a fixed set of volatile delivery-id keys is removed (recursively); stable facts (status, channel, target, action) and the argsHash gate remain, so distinct messages stay distinguishable (covered by the no-false-positive regression test).
• Risk: behavior change could surface previously-hidden blocks. Mitigation: the change is scoped to the send family and merely lets the existing critical/no-progress thresholds apply as designed; no threshold, cap, or other detector/tool is altered.

Change Type (select all)

• Bug fix

Scope (select all touched areas)

• Agents / tools

Linked Issue/PR

Fixes #89090