openclaw - 💡(How to fix) Fix Add per-agent config to disable [[reply_to_current]] directive and auto-send [1 comments, 1 participants]

Background

OpenClaw supports two output directives for messaging:

• [[reply_to_current]] — replies to the triggering inbound message
• [[reply_to:<id>]] — replies to a specific message id

The default [[reply_to_current]] is convenient but in practice can cause threading drift when a topic spans multiple turns:

• User starts a topic with message A
• User sends follow-up B (replying to A)
• Agent uses [[reply_to_current]] → reply hangs off B, not A
• User loses ability to trace the full topic from the topic root

For agents that should always anchor replies to the topic root, the agent author currently has only soft constraints (SOP/skill files instructing the agent to use message thread-reply tool with the explicit topic-root id). There is no runtime-level guard.

Problem

Soft constraints don't reliably prevent agent drift. Agents trained on convenience patterns (or under context pressure) will occasionally fall back to [[reply_to_current]] even when their SOP forbids it. Authors can only catch violations post-hoc.

Proposed Feature

Add an optional per-agent config to disable specific directives at the runtime level:

{
  "agents": {
    "list": {
      "<agent-id>": {
        "directives": {
          "replyToCurrent": "disabled"
        }
      }
    }
  }
}

When disabled:

• Runtime strips the [[reply_to_current]] tag from outbound text
• Runtime emits a warning to the agent's next turn (so the agent learns to avoid it)
• Optionally: log the violation for the operator

Replies still work via the message tool with explicit messageId (the recommended path anyway).

Why Not Solve in Userland

The directive is parsed in OpenClaw's directive-tags runtime module. There is no exposed pre-send / outbound hook for userland scripts to intercept. The only userland workarounds are:

1. SOP / skill instructions (soft, doesn't prevent)
2. Post-hoc audit of session jsonl (tripwire only, after the fact)
3. Patching the dist bundle (fragile, broken on next upgrade)

A small config flag in core would be the cleanest solution.

Backward Compatibility

• Default behavior unchanged (replyToCurrent: "enabled")
• Opt-in only — existing agents unaffected
• No migration required

Implementation Sketch

In directive-tags-*.js:

• Read agents.<id>.directives.replyToCurrent from runtime config
• If disabled, replace match with empty string before parsing
• Surface a single line in next-turn system context: [runtime warning] reply_to_current directive is disabled for this agent; use message tool with explicit messageId

Addendum: Auto-send suppression

Additional Problem

Beyond [[reply_to_current]], there is a more fundamental issue: any text output by the assistant is automatically sent as a message to the channel. There is no per-agent config to disable this.

For agents that should ONLY communicate via explicit message tool calls (e.g., to control threading or prevent narration leakage), intermediate narration text between tool calls leaks as independent messages without reply context.

Proposed Solution (extended)

In addition to replyToCurrent: "disabled", add:

{
  "agents": {
    "list": {
      "<agent-id>": {
        "autoReply": false
      }
    }
  }
}

When autoReply: false:

• Assistant text output is NOT automatically sent to the channel
• Only explicit message tool calls produce visible output
• NO_REPLY behavior becomes the default (no need for the agent to output it)
• This eliminates narration leakage at the runtime level

Impact

Without this, the only mitigation is agent self-discipline (not outputting text between tool calls), which is fragile and repeatedly fails in practice.