Summary

/stop slash command fails to reliably halt an agent that is processing a backlog of queued messages. The abort lands between sequential runs (no_active_run), and the agent immediately starts processing the next queued message, making it impossible for the user to interrupt a stuck agent.

Steps to Reproduce

1. Send an agent multiple messages in quick succession (e.g. a multi-step task)
2. Agent begins processing messages sequentially (one run per message)
3. Agent enters an error loop during processing (e.g. repeatedly failing an authentication step via browser automation)
4. User sends /stop in the same chat to halt the agent
5. /stop fails — agent continues processing the next queued message

Expected Behavior

/stop should:

1. Abort the currently active run (if any), and
2. Drain/discard the pending message queue for that session, preventing subsequent queued messages from triggering new runs

Actual Behavior

• /stop only attempts to abort the current active run
• If the command arrives between two sequential runs (after one completes, before the next starts), the abort fails with no_active_run
• The agent immediately starts a new run from the next queued message
• User has no way to interrupt the agent via Telegram — must resort to gateway restart

Evidence from Logs

abort failed: sessionId=<redacted> reason=no_active_run

Multiple sequential runs show aborted=false, confirming the abort never hit an active run. The agent processed 10+ consecutive runs without stopping.

Note on Voice Messages

This issue is exacerbated with voice messages, as each requires ASR transcription before agent processing, increasing per-run duration and queue depth. However, the core bug applies to all message types — any long-running tool call (e.g. browser automation with repeated screenshots) can create the same abort gap with text messages.

Impact

• High severity for end users: When an agent enters an error loop (e.g. repeatedly entering wrong credentials on a website), the user cannot stop it, risking account lockouts or other cascading failures
• The only reliable workaround is gateway restart, which disrupts all agents, not just the problematic one

Proposed Solution

When /stop is received:

1. Set an abortRequested flag on the session
2. Abort the current run if active
3. Drain the inbound message queue for that session (or mark them as skipped)
4. Any new run attempt on that session should check the flag and refuse to start until the user sends a new message

This would make /stop a true "emergency brake" rather than a narrow single-run abort.

Environment

• OpenClaw: 2026.2.22-2 (45febec)
• Platform: Telegram (multi-agent, multi-bot setup)
• Agent processing mode: embedded (sequential)