🚨 Critical: AI ignores user interrupt signals during long-running tasks

Summary

When a user sends an interrupt signal (/stop, /abort, or explicit "stop" commands) during a long-running task execution, the AI continues executing the task and ignores all user commands. The chat.abort signal is received by the gateway but not propagated to the running AI task.

Severity: Critical - Users lose control of the AI agent during long operations.

Evidence Timeline

Date: 2026-04-04, 01:08-01:34 (GMT+8)

Root Cause Analysis

1. Interrupt Signal Not Propagated

Gateway logs show:

2026-04-04T01:14:05.743+08:00 [ws] ⇄ res ✓ chat.abort 113ms

The chat.abort command was successfully received by the gateway, but the AI task continued executing.

Expected: The AI should immediately stop all operations and ask the user for further instructions.

Actual: The AI continued polling the download progress, ignoring the abort signal.

2. Session State Lock

During long-running task execution:

• New user messages cannot enter the processing queue
• Messages are dropped without logging
• Session enters a "locked" state

Evidence: Messages sent between 01:14-01:24 are not recorded in the session transcript (~/.openclaw/agents/main/sessions/*.jsonl).

3. Loop Detection Failed

Configuration:

"loopDetection": {
  "enabled": true,
  "historySize": 30,
  "warningThreshold": 8,
  "criticalThreshold": 15,
  "globalCircuitBreakerThreshold": 25,
  "detectors": {
    "genericRepeat": true,
    "knownPollNoProgress": true,
    "pingPong": true
  }
}

Despite configuration, the AI repeatedly executed "download → check progress" loops without triggering any detection.

4. Abort Signal Cascade

At 09:31, the gateway received an abort signal and stopped all services:

2026-04-04T09:31:01.718+08:00 [feishu] abort signal received, stopping
2026-04-04T09:31:01.720+08:00 [gmail-watcher] gmail watcher stopped

This suggests the abort signal was not properly isolated to the specific session.

Reproduction Steps

1. Start OpenClaw gateway: openclaw gateway start
2. Send a long-running command (e.g., brew install --cask claude-code)
3. During execution, send /stop or /abort or explicit "停止执行" command
4. Observe: AI continues executing the task
5. Try sending additional commands - they will be ignored
6. Wait for task completion - AI reports result as if nothing happened

Reliability: 100% reproducible with tasks >2 minutes

Expected Behavior

1. Immediate interrupt: AI should stop all operations within 1-2 seconds of receiving abort signal
2. Process cleanup: Any background processes (brew, npm, etc.) should be terminated
3. User confirmation: AI should acknowledge the interrupt and ask for next steps
4. Message queue: New user messages should always be processable, even during long tasks

Actual Behavior

1. ❌ AI ignores abort signal and continues task
2. ❌ Background processes continue running
3. ❌ No acknowledgment of interrupt
4. ❌ New messages are dropped/ignored
5. ❌ Gateway may crash due to abort signal cascade

Impact Assessment

User Impact

• Loss of control: Cannot stop runaway tasks
• Resource waste: CPU, network, API calls continue unnecessarily
• Frustration: User must manually kill processes or restart gateway
• Trust erosion: AI appears "stubborn" or "broken"

System Impact

• Gateway instability: Abort signals can crash the entire service
• Message loss: User commands are dropped without logging
• Session corruption: Sessions can enter locked states

Environment

OpenClaw Version: 2026.4.2 (d74a122)
Node.js: v25.6.1
OS: macOS 26.4 (Darwin 25.4.0, arm64)
Model: bailian/glm-5
Thinking Level: medium
Session Store: ~/.openclaw/agents/main/sessions/sessions.json

Configuration highlights:

• loopDetection.enabled: true (not working)
• session.idleMinutes: 120
• agents.defaults.heartbeat.every: 15m
• agents.defaults.maxConcurrent: 4

Logs & Evidence

Gateway Log Excerpt

2026-04-04T01:08:08.451+08:00 [ws] ⇄ res ✓ sessions.list 180ms
2026-04-04T01:14:05.743+08:00 [ws] ⇄ res ✓ chat.abort 113ms  # User sent abort
2026-04-04T01:14:05.947+08:00 [ws] ⇄ res ✓ sessions.list 182ms  # But AI continued
2026-04-04T09:31:01.718+08:00 [feishu] abort signal received, stopping  # Gateway crashed

Session Transcript

• Session ID: dd3f655b-e591-4fe6-90e8-18f3814329a4
• File: memory/2026-04-04-claude-install.md
• Shows AI continued reporting progress after abort signal

Configuration

• Full config available at: ~/.openclaw/openclaw.json
• Sessions: ~/.openclaw/agents/main/sessions/sessions.json

Suggested Fix

Short-term (Agent Level)

1. Add interrupt checking in task loops: Before each iteration, check if user has sent new commands
2. Implement "stop words" detection: Recognize /stop, /abort, "停止", "cancel" as immediate interrupts
3. Add timeout to polling operations: Don't poll indefinitely without checking user input

Long-term (Platform Level)

1. Propagate chat.abort to AI task: The gateway should signal the running AI agent to stop
2. Implement task cancellation tokens: Similar to C# CancellationToken or Go context.Context
3. Fix session state lock: Ensure new messages can always enter the processing queue
4. Isolate abort signals: Don't cascade abort to other services/sessions
5. Fix loop detection: Actually trigger when AI repeats similar actions

Architecture Suggestion

// Pseudocode for interrupt propagation
class AITask {
  private abortController = new AbortController();
  
  async execute() {
    while (!this.abortController.signal.aborted) {
      // Check for user interrupts
      if (await this.hasUserInterrupt()) {
        await this.cleanup();
        return { status: 'aborted', reason: 'user_request' };
      }
      
      // Continue task execution
      await this.step();
    }
  }
  
  abort() {
    this.abortController.abort();
  }
}

Related Issues

• #31575 - TUI streaming state stuck (similar lock behavior)
• #60396 - Token fallback feature request (context window issues)

Workaround for Users

Until this is fixed, users can:

1. Force interrupt: Press Ctrl+C in TUI to forcefully interrupt
2. Restart gateway: openclaw gateway restart to clear locked sessions
3. Set task boundaries: Tell AI "This task may take long, check for my commands every 30 seconds"
4. Use /reset: Reset the session if AI becomes unresponsive

Priority

🔴 Critical - This affects basic user control and system stability.

Users should be able to stop any AI operation at any time. This is a fundamental safety requirement for AI agents.

Additional Context

This issue was discovered during a brew install task that took ~16 minutes. The user sent multiple stop commands that were all ignored. The gateway eventually crashed due to abort signal cascade.

Session memory file: memory/2026-04-04-claude-install.md User report: "你在执行长时间任务的时候，容易陷入一种奇怪的状态，忽略我的任何指令，只知道完成当前任务，我重启都没有用"

/cc @openclaw/core-team - This requires immediate attention for user safety and trust.