Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix Subagent announcement pushed to wrong channel (webchat instead of dingtalk-connector) [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#52796•Fetched 2026-04-08 01:19:16
View on GitHub
Comments
0
Participants
1
Timeline
2
Reactions
0
Author
0-0-0-0-0-0-00-0-0-0-0-0-0
Participants
0-0-0-0-0-0-00-0-0-0-0-0-0
Timeline (top)
closed ×1locked ×1

Root Cause

The session's deliveryContext.channel is set to 'webchat' even when the session was created from a dingtalk-connector message. This appears to be a session routing issue in OpenClaw's core.

From the session inspection:

  • Session key contains: channel":"dingtalk-connector
  • But deliveryContext shows: channel: "webchat"
  • This causes subagent announcements to route to webchat instead of dingtalk-connector

Fix Action

Fix / Workaround

This was first noticed when subagent tasks complete successfully but the completion notification arrives in webchat rather than the dingtalk conversation where the user is actually chatting. The workaround has been to manually relay results from webchat, but this is not sustainable.

RAW_BUFFERClick to expand / collapse

Problem

When a subagent completes a task and announces the result, the announcement is pushed to the webchat channel instead of the original channel (dingtalk-connector) that the user is actually using.

Steps to Reproduce

  1. User sends a message via dingtalk-connector
  2. Main agent spawns a subagent to handle the task
  3. Subagent completes and announces result
  4. Result is received in webchat channel, NOT in dingtalk-connector

Expected Behavior

Subagent announcements should be delivered to the channel where the user sent the original message (dingtalk-connector in this case).

Root Cause Analysis

The session's deliveryContext.channel is set to 'webchat' even when the session was created from a dingtalk-connector message. This appears to be a session routing issue in OpenClaw's core.

From the session inspection:

  • Session key contains: channel":"dingtalk-connector
  • But deliveryContext shows: channel: "webchat"
  • This causes subagent announcements to route to webchat instead of dingtalk-connector

Environment

  • OpenClaw version: Latest
  • DingTalk connector version: 0.8.1
  • Channel: dingtalk-connector

Additional Context

This was first noticed when subagent tasks complete successfully but the completion notification arrives in webchat rather than the dingtalk conversation where the user is actually chatting. The workaround has been to manually relay results from webchat, but this is not sustainable.

extent analysis

Fix Plan

To fix the session routing issue, we need to update the deliveryContext.channel to match the original channel used by the user. We can achieve this by modifying the session creation logic in OpenClaw's core.

Step-by-Step Solution

  1. Update Session Creation Logic: In the session creation function, extract the original channel from the session key and set it as the deliveryContext.channel.
  2. Modify Delivery Context: Update the deliveryContext object to use the extracted channel instead of hardcoding it to 'webchat'.

Example Code

# Assuming session creation function is create_session()
def create_session(session_key, ...):
    # Extract original channel from session key
    original_channel = json.loads(session_key)['channel']
    
    # Create session with updated delivery context
    session = {
        'key': session_key,
        'deliveryContext': {
            'channel': original_channel  # Set channel to original channel
        }
    }
    return session

Verification

To verify the fix, follow these steps:

  • Send a message via dingtalk-connector
  • Verify that the subagent announcement is delivered to the dingtalk-connector channel
  • Check the session inspection to ensure deliveryContext.channel matches the original channel

Extra Tips

  • Ensure that the session_key is properly formatted to include the original channel information.
  • Test the fix with different channels and scenarios to ensure the solution is robust.

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…
#file not found#serialization error#model compatibility#GPU setup#container setup

Still need to ship something?

×6

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

Back to top recommendations

TRENDING