openclaw - 💡(How to fix) Fix [Bug]: Google Chat group session keys not created — replies route to WhatsApp instead of Chat [1 comments, 2 participants]

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Google Chat plugin collapses all group space messages into the main session key (e.g. agent:verdant:main) instead of creating the correct group session key (agent:verdant:googlechat:group:spaces/AAQA7VDFED). As a result, agent replies are delivered to the user's most recently active channel (WhatsApp) instead of back to the originating Google Chat group. This is the same class of bug as #45514 (multi-channel routing sends replies to wrong channel) combined with the Google Chat DM routing bug in #9198 — Google Chat inbound is not respecting channel+peer routing.

Steps to reproduce

1. Run OpenClaw with both WhatsApp and Google Chat channels configured.
2. Apply this binding configuration:

{
  "bindings": [
    { "match": { "channel": "whatsapp" }, "agentId": "digital-d" },
    { "match": { "channel": "googlechat", "peer": { "kind": "group", "id": "spaces/AAQA7VDFED" } }, "agentId": "verdant" }
  ],
  "channels": {
    "googlechat": {
      "enabled": true,
      "serviceAccountFile": "/home/<redacted>/.config/gws/bot-<redacted>.json",
      "audience": "https://chat.<redacted>.googlechat",
      "webhookPath": "/googlechat",
      "dm": { "policy": "pairing" },
      "groupPolicy": "open",
      "appPrincipal": "<redacted>",
      "groups": { "spaces/AAQA7VDFED": { "enabled": true, "requireMention": false } },
      "groupAllowFrom": ["spaces/AAQA7VDFED", "users/<redacted>"]
    }
  },
  "session": { "dmScope": "per-account-channel-peer" }
}

1. Send @bot hello in Google Chat group spaces/AAQA7VDFED.
2. Check the gateway logs for the session key — observe sessionKey=agent:verdant:main (should be agent:verdant:googlechat:group:spaces/AAQA7VDFED).
3. Observe the reply arrives on WhatsApp (+1<redacted>) instead of Google Chat.

Expected behavior

Per Channel Routing docs:

• Google Chat group messages should create session key: agent:<agentId>:googlechat:group:<spaceId>
• e.g. agent:verdant:googlechat:group:spaces/AAQA7VDFED
• Replies should route back to the originating channel (Google Chat)

Actual behavior

• Session key created: agent:verdant:main (incorrect — defaults to main session)
• Reply sent to: WhatsApp (+1<redacted>) instead of Google Chat group
• Gateway logs show: sessionKey=agent:verdant:main for all Google Chat group messages
• The channel plugin ignores the peer.kind: group matching and collapses to main

OpenClaw version

2026.5.7

Operating system

Linux 6.17.0-1014-nvidia (arm64) v24.13.1

Install method

openclaw update

Model

vllm/Intel/Qwen3.6-35B-A3B-int4-AutoRound

Provider / routing chain

GoogleChat plugin (webhook → OpenClaw gateway → agent → reply delivery)

Additional provider/model setup details

• OpenClaw Version: 2026.5.7
• OS: Linux 6.17.0-1014-nvidia (arm64), Ubuntu 24.04
• Node: v24.13.1
• Hardware: NVIDIA DGX Spark (Founder Edition)
• Channels active: WhatsApp (selfChatMode), Google Chat (webhook with SA auth)
• SA key path: /home/<redacted>/.config/gws/bot-<redacted>.json
• Session scope: dmScope: per-account-channel-peer (configured but doesn't affect group routing)
• Google Chat plugin uses SA token auth via verdant-<redacted>.json
• appPrincipal: 117689656528733314485 set on tunnel
• Binding correctly routes to agent verdant — but session key resolution happens in the plugin, not the binding layer

Logs, screenshots, and evidence

Expected log line: `sessionKey=agent:verdant:googlechat:group:spaces/AAQA7VDFED`
Actual log line: `sessionKey=agent:verdant:main`

Binding config:

{
  "match": {
    "channel": "googlechat",
    "peer": { "kind": "group", "id": "spaces/AAQA7VDFED" }
  },
  "agentId": "verdant"
}

Binding correctly matches and routes to agent `verdant`, but the Google Chat channel plugin does not construct the group session key. It collapses to `agent:verdant:main`.

Related issues (same root class):
- #79395 — Google Chat Group Session Key Not Created - Replies Route to Wrong Channel
- #9198 — Google Chat DM routing ignores bindings, always routes to default agent main
- #45514 — Multi-channel routing sends replies to lastChannel instead of origin channel
- #4530 — Multi-channel response routing leaks when messages arrive simultaneously
- #69422 — Google Chat outbound: thread/reply routing metadata leaks across streamed blocks

Impact and severity

• Affected users: All users communicating with agents via Google Chat group spaces in multi-channel setups
• Severity: High — privacy leak (sensitive group content routed to wrong recipient on WhatsApp), conversation context cross-contamination between channels
• Frequency: Always (100% for Google Chat group messages when another channel is active)
• Consequence: Users receive agent replies on WhatsApp instead of Google Chat. Sensitive group discussion content leaks to unintended recipients. Context from one channel bleeds into another.

Additional information

This is a follow-up to issue #79395 which was auto-closed by the triage bot. The issue has been confirmed reproduceable on v2026.5.7 running on NVIDIA DGX Spark.

Root cause analysis: The session key is determined by the channel plugin at inbound webhook ingress, not by the binding layer. The Google Chat plugin collapses all group messages to the main session regardless of peer.kind: group matching in bindings. This is consistent with #9198 where Google Chat DMs also bypass binding routing.

Workarrows tried (none work):

• Disabling other channels temporarily: only works if ALL other channels are disabled
• session.dmScope: per-account-channel-peer: already configured, has no effect on group session key creation

Suggested fix:

1. Update the Google Chat plugin to construct proper group session keys at webhook ingress using the peer.id from the event payload
2. Ensure the session key format follows the spec: agent:<agentId>:googlechat:group:<spaceId>
3. Route reply delivery to the channel stored in the session key, not the most recently active channel
4. Apply similar fix to DM handling (see #9198)