Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix CRITICAL: Agent ignores stop commands during exec denial - infinite retry loop, delayed command flood, and queue overflow [1 pull requests]

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

gateway timeout after 45000ms gateway connect failed: Error: gateway closed (1000)

Fix Action

Fixed

PR fix notes

PR #69387: Fix: CRITICAL: Agent ignores stop commands during exec denial - infinite retry loop, delayed command flood, and queue overflow

Description (problem / solution / changelog)

To resolve the issue of the agent ignoring stop commands and entering an infinite retry loop during execution denials, I implemented a 'consecutive denial protection' mechanism in runTaskInFlow. This fix addresses the critical loop by: 1) Scanning the task history of the current flow for consecutive terminal tasks that resulted in a 'denied', 'rejected', or 'blocked' status (using both outcome codes and common localized keywords). 2) If the denial threshold (N=3) is met, the system automatically requests a flow cancellation via markFlowCancelRequested and refuses to create new tasks, returning a descriptive reason to the agent orchestrator. This stops the command flood and prevents message queue overflow by breaking the automatic feedback loop. It also ensures that the user's manual stop commands can eventually be processed once the agent turn cycle is halted.

Test: 1. Start a task flow that requires 'exec' tool calls. 2. Mock the tool execution to return 'Permission denied' for 3 consecutive calls. 3. Call runTaskInFlow for a 4th attempt. 4. Verify that the result returns created: false with a reason indicating consecutive denials and that the flow's cancelRequestedAt property is set.

Changed files

  • src/tasks/task-executor.ts (modified, +90/-83)

Code Example

Exec denied → Agent responds → tries new command → Exec denied → Agent responds → ...

---

[Queue overflow] Dropped 47 messages due to cap.

---

gateway timeout after 45000ms
gateway connect failed: Error: gateway closed (1000)
RAW_BUFFERClick to expand / collapse

Bug Report: Agent Ignores Stop Commands During Exec Approval Loop

Severity

🔴 Critical

Environment

  • OpenClaw Version: 2026.4.15
  • Platform: Windows 11 (NT 10.0.26200, x64)
  • Node: v25.9.0
  • Model: alibailian/qwen3.6-plus
  • Channel: webchat (Control UI)
  • Agent: trade

Reproduction Steps

  1. User requests a task that requires exec commands (e.g., installing a skill from Iwencai SkillHub)
  2. User consistently denies all exec approval requests
  3. User repeatedly types "停下来" (stop) in chat
  4. Agent does NOT stop. Instead, it tries 10+ different variations of exec commands, each getting denied.

Bug 1: Agent Cannot Stop on Denial / Ignores Stop Commands

Expected behavior: After 2-3 consecutive exec denials, the agent should stop trying and ask the user for guidance.

Actual behavior: The agent enters an infinite retry loop, trying different command variations (PowerShell, Python, batch files, WebClient, Invoke-WebRequest, etc.) despite every single one being denied. The agent even said "需要批准" (needs approval) when the user was clearly denying all requests.

Timeline: ~25 minutes, 15+ exec commands attempted, all denied.

Bug 2: "An async command did not run" Completion Details Trigger Unwanted Agent Responses

Expected behavior: Completion details for denied commands should NOT trigger a new agent turn, or should be suppressed when the user has sent stop commands.

Actual behavior: Every Exec denied completion detail fires an automatic agent response, creating a feedback loop:

Exec denied → Agent responds → tries new command → Exec denied → Agent responds → ...

This loop continued despite 47+ user messages saying "停下来".

Bug 3: Delayed Commands Not Visible in Command Queue

Expected behavior: All pending/executing commands should be visible in the command queue UI.

Actual behavior: Delayed commands (from previous turns) executed and returned denied notifications WITHOUT appearing in the visible command queue. The user had no way to see, manage, or cancel them.

Bug 4: Message Queue Overflow

Expected behavior: User messages should be processed in order.

Actual behavior: 47 messages were dropped due to queue overflow:

[Queue overflow] Dropped 47 messages due to cap.

User's stop commands and additional context (like providing log file paths) were lost.

Bug 5: Stop/Deny Commands Not Recognized as High Priority

Expected behavior: Words like "停下来", "stop", "暂停", and continuous denial should immediately pause the current task and enter an interpret/wait state.

Actual behavior: The agent only stopped after the user sent the same message 20+ times over 10+ minutes.

Impact

  • User experience: Extremely frustrating. User had to send 47+ messages to stop a runaway loop.
  • Token waste: Excessive API calls and token consumption from retry loops.
  • Context loss: Queue overflow dropped 47 messages including important user context.
  • Trust: User loses confidence in the system's ability to follow basic stop commands.

Recommended Fixes

  1. Auto-stop after N consecutive denials (N=2 or 3): Agent should recognize a pattern of denials and halt, asking the user for intent.
  2. Suppress auto-responses to denied completion details: When exec is denied, do NOT automatically trigger an agent turn. Only respond if the user explicitly asks.
  3. Priority interrupt for stop commands: "停下来", "stop", "暂停" etc. should be recognized as highest-priority interrupts that cancel all pending operations.
  4. Show delayed commands in queue: All pending/executing commands should be visible and cancellable.
  5. Increase message queue capacity or implement priority queuing so stop commands are never dropped.
  6. Enter interpret state on stop: When user sends a stop command, agent should reply briefly and wait for user input, not continue the previous task flow.

Log Excerpt

Gateway log at D:\tmp\openclaw\openclaw-2026-04-20.log:

gateway timeout after 45000ms
gateway connect failed: Error: gateway closed (1000)

Gateway instability during the session may have compounded the issue.

extent analysis

TL;DR

Implementing an auto-stop feature after a specified number of consecutive denials and prioritizing stop commands can help mitigate the issue of the agent ignoring stop commands during exec approval loops.

Guidance

  • Implement auto-stop after N consecutive denials: Set a threshold (e.g., N=2 or 3) for consecutive denials after which the agent should halt and ask the user for intent.
  • Suppress auto-responses to denied completion details: Modify the agent to not automatically trigger a new turn when an exec command is denied, unless the user explicitly asks for a response.
  • Recognize stop commands as high-priority interrupts: Ensure that commands like "停下来", "stop", "暂停" are recognized as highest-priority interrupts that cancel all pending operations.
  • Review and adjust message queue capacity: Increase the message queue capacity or implement priority queuing to prevent dropping important user messages, especially stop commands.
  • Verify gateway stability: Investigate the gateway log errors (e.g., gateway timeout after 45000ms, gateway connect failed: Error: gateway closed (1000)) to ensure they are not contributing to the issue.

Example

No specific code example is provided due to the complexity and variability of the system's architecture. However, the logic for auto-stopping after consecutive denials could be implemented using a counter that increments with each denial and triggers a halt action when the threshold is reached.

Notes

The provided log excerpt suggests potential gateway instability, which may exacerbate the issue. Addressing this could be crucial in fully resolving the problem. Additionally, the fixes recommended should be tested thoroughly to ensure they do not introduce new issues or affect the system's performance.

Recommendation

Apply the workaround by implementing an auto-stop feature and prioritizing stop commands. This approach directly addresses the core issue of the agent ignoring stop commands and entering an infinite retry loop, thereby improving user experience and reducing unnecessary API calls and token consumption.

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…
#api#LLM response#prompt template#agent execution#callback error

Still need to ship something?

×6

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

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix CRITICAL: Agent ignores stop commands during exec denial - infinite retry loop, delayed command flood, and queue overflow [1 pull requests]