Summary

Google Chat spaces were unreliable or broken in several ways on OpenClaw 2026.4.10:

1. Chat add-on style payloads in Google Chat were parsed too narrowly, which caused valid events to be rejected as invalid payload.
2. groups: { "*": { requireMention: true } } did not actually behave as documented unless a separate group sender allowlist was also present.
3. Replies in spaces could fail with Google Chat API 400: The request contains an invalid thread resource name.

Environment

• OpenClaw 2026.4.10
• Global install under /opt/homebrew/lib/node_modules/openclaw
• Google Chat channel with audienceType: "app-url"
• Google Chat space routing to a restricted team agent

Symptoms

• Google Cloud logs showed invalid payload / Can't handle the app's response for some space events.
• Google Chat space mentions reached the gateway but were blocked until botUser was set and sender policy was relaxed.
• After delivery into the agent worked, some replies still failed with:

Google Chat API 400:
The request contains an invalid thread resource name

Root Causes

1. Add-on payload parsing too narrow

In parseGoogleChatInboundPayload, the code only handled:

rawObj.commonEventObject?.hostApp === "CHAT" && rawObj.chat?.messagePayload

That misses other valid Chat payloads such as:

• chat.addedToSpacePayload
• chat.removedFromSpacePayload

2. Group sender policy contradicted docs

The runtime used:

const senderGroupPolicy =
  groupConfigResolved.allowlistConfigured && normalizedGroupUsers.length === 0
    ? groupPolicy
    : resolveSenderScopedGroupPolicy({ groupPolicy, groupAllowFrom: normalizedGroupUsers });

With groupPolicy: "allowlist" and groups["*"] configured, but no explicit groupAllowFrom, that effectively kept sender policy at allowlist and blocked group messages.

This contradicts the documented pattern that groups: { "*": { requireMention: true } } should allow all groups while only replying on mention.

3. Outbound reply used the wrong thread identifier

Google Chat inbound context stores:

• currentMessageId as the message id
• ReplyToId as the thread resource

When an agent used [[reply_to_current]], the reply pipeline could prefer the current message id. The Google Chat sender then passed that value as:

thread: payload.replyToId

which is invalid when the value is a message resource instead of:

spaces/<space>/threads/<thread>

Working Local Fix

The local fix that worked was:

1. Accept add-on payload variants in parseGoogleChatInboundPayload
2. Resolve sender group policy directly from resolveSenderScopedGroupPolicy
3. Normalize outbound Google Chat thread ids and prefer a valid spaces/.../threads/... resource

Suggested Upstream Fix

• Expand Google Chat add-on payload parsing in parseGoogleChatInboundPayload
• Remove the sender-policy special case that preserves allowlist when groups are configured but groupAllowFrom is empty
• In Google Chat outbound replies, validate replyToId and fall back to the inbound thread resource when replyToId is a message id

Extra Note

Mention detection in Google Chat spaces also required setting botUser explicitly to the real bot user resource, for example users/<id>. The docs already hint at this, but the operational requirement is easy to miss during setup.