openclaw - 💡(How to fix) Fix Dual session created for same channel DM — user messages vs async completions use different session keys [2 comments, 3 participants]

Description

When a user sends a DM via Feishu channel to an agent, the user message is routed to one session key (agent:<agentId>:main), but async completion notifications (exec results, subagent announcements) are routed to a different session key (agent:<agentId>:feishu:<accountId>:direct:<openId>). This creates two parallel sessions for the same conversation, causing state desynchronization.

Environment

• OpenClaw version: 2026.4.15 (041266a)
• Channel: Feishu (websocket mode)
• Agent config: single leader agent with dev-team feishu account binding
• Reproduced with: multiple agents (leader, developer, tester, cto, pm)

Steps to Reproduce

1. Configure a Feishu account bound to an agent:

{
  "bindings": [
    {"type": "route", "agentId": "leader", "match": {"channel": "feishu", "accountId": "dev-team"}}
  ],
  "channels": {
    "feishu": {
      "accounts": ["dev-team"],
      "dmPolicy": "pairing"
    }
  }
}

1. User sends a DM to the bot — this creates session agent:leader:main
2. The agent calls sessions_spawn(agentId="developer", ...) to delegate a coding task
3. The subagent completion notification arrives — but creates a new session agent:leader:feishu:dev-team:direct:ou_<openId>
4. Both sessions now exist in parallel with the same lastChannel, lastTo, and lastAccountId

Evidence

sessions.json shows two active sessions for the same channel + user:

"agent:leader:main": {
    "lastChannel": "feishu",
    "lastTo": "user:ou_171a3c3028b72a1cefa5fca757affb0c",
    "lastAccountId": "dev-team"
},
"agent:leader:feishu:dev-team:direct:ou_171a3c3028b72a1cefa5fca757affb0c": {
    "lastChannel": "feishu",
    "lastTo": "user:ou_171a3c3028b72a1cefa5fca757affb0c",
    "lastAccountId": "dev-team"
}

Session transcript analysis:

The dev-team session is a "ghost" — it has zero user messages but processes subagent completions independently, reporting results the user sees. The main session sleeps through all of this, waking up later with no context of what happened.

Impact

• State desync: main session wakes up and re-discovers task state (re-checks git log, re-reads files) because it has no memory of what the dev-team session processed
• Duplicate work: both sessions may spawn subagents for the same task
• Token waste: main session re-fetches documents, re-runs status checks
• Confusing UX: the user sees responses originating from a session they never directly interacted with

Expected Behavior

All messages (user DMs, exec completions, subagent announcements) for the same channel + agent + user should route to a single session key. Async completions should reuse the existing session key rather than creating a new channel-specific one.

Possible Root Cause

The session key derivation appears inconsistent:

• User messages → agent:<agentId>:main
• Async completions via deliveryContext → agent:<agentId>:<channel>:<accountId>:direct:<openId>

The completion delivery path (ref: subagents docs — "fills the missing target/account from the requester session's resolved route") may be resolving to a different session key than the original user message path.

Workaround

Adding subagents.requireAgentId: true and strict AGENTS.md rules can partially mitigate the confusion, but the root routing issue remains.