Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix Safety: steer messages must interrupt active tool chains at tool boundaries [3 comments, 2 participants]

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…
GitHub stats
openclaw/openclaw#74814•Fetched 2026-05-01 05:41:04
View on GitHub
Comments
3
Participants
2
Timeline
5
Reactions
2
Author
howardclaw26howardclaw26
Participants
clawsweeper[bot]clawsweeper[bot]howardclaw26howardclaw26
Timeline (top)
commented ×3closed ×1cross-referenced ×1

Error Message

  • User sends an initial instruction.
  • Assistant starts a long action/tool chain.
  • User sends corrections while tool calls are visibly still happening.
  • Corrections arrive later as queued-message backlog, after the action chain has already continued for a while.

Root Cause

At scale, users will mistype, send stale instructions, or realize a command is dangerous immediately after sending it. If the system cannot surface corrections until after long tool chains complete, it can cause real accidents: wrong repo writes, messages sent to wrong people, config/deploy damage, or other irreversible actions.

RAW_BUFFERClick to expand / collapse

Problem

Inbound steering currently appears unable to reliably interrupt long active tool chains at the next tool boundary. In a Signal DM configured with messages.queue.mode = steer and byChannel.signal = steer, new corrective messages were delivered only after the assistant completed a long sequence of tool calls.

This is safety-critical, not just UX friction. If a user sends an incorrect instruction, then immediately sends "stop" or a correction, OpenClaw may continue executing the wrong instruction for many tool calls before the correction reaches the active agent loop.

Observed behavior

  • User sends an initial instruction.
  • Assistant starts a long action/tool chain.
  • User sends corrections while tool calls are visibly still happening.
  • Corrections arrive later as queued-message backlog, after the action chain has already continued for a while.

Docs/spec also appear inconsistent:

  • docs/concepts/agent.md says queued steering is delivered after the current assistant turn finishes executing its tool calls, before the next LLM call.
  • docs/concepts/queue.md says steer injects immediately into the current run and cancels pending tool calls after the next tool boundary.

The safe behavior should be the latter, with a hard checkpoint.

Expected behavior / safety contract

For queue mode steer:

  1. After every tool result, before any next tool call is executed, check for pending inbound steering for the same session.
  2. If present, inject the steering into the active run before continuing.
  3. If the steering is a stop/cancel message or queue mode is interrupt-like, cancel pending tool calls before any further side effects.
  4. External/destructive/high-risk tool calls should be especially checkpointed: no queued corrective message should sit unseen while the agent continues issuing writes.
  5. The UI/logging should make it clear whether a message was steered into the active run, delayed to model boundary, or demoted to followup.

Why this matters

At scale, users will mistype, send stale instructions, or realize a command is dangerous immediately after sending it. If the system cannot surface corrections until after long tool chains complete, it can cause real accidents: wrong repo writes, messages sent to wrong people, config/deploy damage, or other irreversible actions.

Suggested implementation direction

  • Add a tool-boundary interrupt/steer checkpoint in the agent tool loop, not only at model-turn boundaries.
  • Make steer semantics explicit and testable: "delivered before the next tool call after the current tool result."
  • Add regression tests with a multi-tool assistant turn where an inbound steer arrives between tool results and must prevent later queued tool calls from executing.
  • Reconcile docs/concepts/agent.md and docs/concepts/queue.md so the documented contract is singular.

Acceptance tests

  • Given an active run with tool calls A, B, C and an inbound steer arrives after A completes, B/C do not execute until the model has seen the steer.
  • Given inbound "stop" arrives after A completes, B/C are canceled.
  • Given collect mode, behavior remains followup-only.
  • Given steer-backlog, message both steers at the tool boundary and remains available for followup according to existing backlog semantics.

extent analysis

TL;DR

Implement a tool-boundary interrupt/steer checkpoint in the agent tool loop to ensure inbound steering is delivered before the next tool call after the current tool result.

Guidance

  • Add a checkpoint after every tool result to check for pending inbound steering and inject it into the active run if present.
  • Implement a mechanism to cancel pending tool calls when a stop/cancel message is received or when the queue mode is interrupt-like.
  • Reconcile the documentation in docs/concepts/agent.md and docs/concepts/queue.md to reflect the updated semantics of steer mode.
  • Develop regression tests to verify the correct behavior of the steer mode, including scenarios where an inbound steer arrives between tool results.

Example

# Pseudo-code example of the proposed checkpoint
def execute_tool_chain(tools):
    for tool in tools:
        # Execute the current tool
        tool_result = execute_tool(tool)
        
        # Check for pending inbound steering
        if has_inbound_steering():
            # Inject the steering into the active run
            inject_steering()
            
            # Cancel pending tool calls if necessary
            if is_stop_or_cancel_message():
                cancel_pending_tool_calls()
        
        # Proceed to the next tool
        # ...

Notes

The implementation details may vary depending on the specific architecture and technology stack of the system. The proposed solution focuses on ensuring that inbound steering is delivered before the next tool call, which is critical for safety and correctness.

Recommendation

Apply the proposed workaround by implementing a tool-boundary interrupt/steer checkpoint in the agent tool loop. This will ensure that inbound steering is delivered in a timely manner, preventing potential accidents and improving the overall safety and reliability of the system.

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…
#memory optimization#batch processing#GPU compatibility#latency issue#model loading

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 - 💡(How to fix) Fix Safety: steer messages must interrupt active tool chains at tool boundaries [3 comments, 2 participants]