openclaw - 💡(How to fix) Fix Feature: Real-time interruption during long tool calls (steer doesn't interrupt running tools) [1 comments, 2 participants]

Problem

When the agent is executing a long-running tool call (e.g., \yt-dlp\ downloading a 200MB video, or \aster-whisper\ transcribing a 3.5h audio), any user messages sent during that time are queued via the \steer\ mechanism but only delivered after the tool call completes.

The docs explicitly state: "Steering does not interrupt a tool call that is already running."

This means if the user wants to correct or redirect the agent mid-execution, they have to wait for the entire tool call to finish (which can take 5-30+ minutes).

Current Behavior

None of these allow real-time mid-tool-call interruption.

Desired Behavior

The ability to interrupt/correct the agent during a long tool call without:

1. Waiting for the tool to finish (current \steer\ limitation)
2. Losing all progress (current \interrupt\ limitation)

Example scenario: \
User: "下载这个视频并转写" Agent: [starts yt-dlp download... ETA 5 minutes] User: "等一下！换个链接" <-- queued, can't be received for 5 minutes Agent: [5 minutes later] Download complete. Oh, you wanted a different link? \\

What should happen: \
User: "下载这个视频并转写"
Agent: [starts yt-dlp download...] User: "等一下！换个链接" Agent: [receives message mid-download, cancels current download, starts new one] \\

Suggested Implementation

1. Add a \ imeoutMs\ or \checkIntervalMs\ option for long tool calls
2. Agent periodically checks for queued user messages during long operations
3. If interruption detected, agent can decide to cancel/modify/continue

Environment

• OpenClaw 2026.5.7
• QQ Bot channel
• Windows 11