Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix Subagent/cron completion events route to wrong sender's session (cross-contamination) [1 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#60941•Fetched 2026-04-08 02:45:22
View on GitHub
Comments
0
Participants
1
Timeline
2
Reactions
0
Author
swryderswryder
Participants
swryderswryder
Timeline (top)
mentioned ×1subscribed ×1
RAW_BUFFERClick to expand / collapse

Bug Description

When a subagent or cron task completes while the agent is mid-turn handling a different user's request, the completion output routes to the currently active requester instead of the originating session/sender.

This causes two user-visible symptoms:

  1. NO_REPLY token leaking — the agent produces NO_REPLY (intended as a gateway suppression signal) but it arrives as visible text in the wrong user's Slack DM
  2. Duplicate/cross-contaminated replies — completion content meant for one user (or for background processing) gets delivered to an unrelated user who happens to have a pending request

Steps to Reproduce

  1. User A DMs the agent (Slack DM)
  2. While the agent is processing User A's request, a previously spawned subagent or cron task completes
  3. The completion event is delivered into the agent's active session
  4. The agent processes the completion and produces output
  5. Output routes to User A (the current "reply target") instead of the original requester or being silently queued

Expected Behavior

Subagent/cron completion events should be tagged with the originating session/sender context (replyTo / onBehalfOf) and routed back only to the matching session. If no matching session is active, completions should queue rather than cross-contaminate into an unrelated in-flight request.

Actual Behavior

Completions land in whatever session is currently active, regardless of who spawned them. This leaks internal signals (NO_REPLY) and cross-contaminates responses between unrelated users.

Environment

  • OpenClaw version: 2026.4.2 (also reproduced on 2026.4.1)
  • Channel: Slack
  • Setup: Multiple users DM the same bot, with cron jobs and subagent tasks running in the background

Suggested Fix

Each spawned task (subagent, cron completion) should carry a session affinity tag tying the completion back to the originating sender/session. The gateway should:

  • Route completions only to the originating session
  • Queue silently if no matching session is active
  • Never deliver completions into an unrelated pending request

/cc @openperf

extent analysis

TL;DR

Implement session affinity tags for subagent and cron task completions to ensure they are routed back to the originating session.

Guidance

  • Introduce a unique session identifier (replyTo / onBehalfOf) for each user request, which is propagated to spawned subagents and cron tasks.
  • Modify the gateway to check for this session identifier when routing completion events, delivering them only to the matching session.
  • If no matching session is active, queue the completion event silently instead of routing it to an unrelated session.
  • Review the current implementation of NO_REPLY token handling to prevent it from being sent as visible text to users.

Example

# Pseudo-code example of adding session affinity tag
subagent_task = spawn_subagent(user_request)
subagent_task.metadata['replyTo'] = user_request.session_id

# ...

# Pseudo-code example of routing completion events
def route_completion_event(event):
    if event.metadata['replyTo'] == current_session_id:
        deliver_event_to_session(event)
    else:
        queue_event(event)

Notes

The suggested fix assumes that the replyTo / onBehalfOf mechanism is already implemented in the OpenClaw version being used. If not, additional work may be required to introduce this functionality.

Recommendation

Apply the suggested fix by introducing session affinity tags and modifying the gateway to route completion events accordingly, as this should effectively prevent NO_REPLY token leaking and duplicate/cross-contaminated replies.

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…
#container setup#orchestration issue#cache issue#memory leak#API versioning

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING