openclaw - ✅(Solved) Fix [Bug]: Google Chat: Space/Group messages silently ignored (DMs work correctly) [1 pull requests, 1 comments, 2 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#58514Fetched 2026-04-08 02:01:47
View on GitHub
Comments
1
Participants
2
Timeline
6
Reactions
0
Timeline (top)
labeled ×2commented ×1cross-referenced ×1mentioned ×1

Google Chat Space/Group messages are received (HTTP 200) but silently ignored; DMs work correctly. Tested with both Add-on and standard Chat API apps.

Root Cause

Google Chat Space/Group messages are received (HTTP 200) but silently ignored; DMs work correctly. Tested with both Add-on and standard Chat API apps.

Fix Action

Fix / Workaround

Workaround: Use DMs only (works perfectly).

PR fix notes

PR #58993: fix(googlechat): support spaceType field for DM vs Space detection

Description (problem / solution / changelog)

Summary

  • Add spaceType and singleUserBotDm fields to the GoogleChatSpace type
  • Update DM detection logic to check all three API fields: legacy type, modern spaceType, and singleUserBotDm

Details

Google Chat API deprecated the space.type field ("DM" | "ROOM") in favor of space.spaceType ("DIRECT_MESSAGE" | "SPACE") and the boolean space.singleUserBotDm. When the legacy type field is absent or empty, the existing check (space.type ?? "").toUpperCase() !== "DM" always evaluates to true, causing all messages to be classified as group messages.

Group messages are subject to group policy evaluation (allowlist, mention gating, etc.) and may be silently dropped if no group is configured, which is the behavior reported in the issue: Space/Group messages return HTTP 200 but no session is created.

The fix falls through all three fields so both legacy and current API payload formats are handled correctly.

Fixes #58514

Test plan

  • Verify DMs still work when space.type is "DM" (legacy format)
  • Verify DMs work when space.spaceType is "DIRECT_MESSAGE" (modern format)
  • Verify DMs work when space.singleUserBotDm is true
  • Verify Space/Group messages are correctly identified as groups and processed according to group policy

🤖 Generated with Claude Code

Co-Authored-By: Claude Opus 4.6 (1M context) [email protected]

Changed files

  • extensions/googlechat/src/monitor.ts (modified, +10/-2)
  • extensions/googlechat/src/types.ts (modified, +4/-0)

Code Example

Caddy access log (Space message received):
1774979423.83 200 /googlechat-raa-v2

OpenClaw sessions created (only DMs, no groups):
agent:raa:googlechat:direct:spaces/mlopdsaaaae  ← DM works
agent:raa:googlechat:direct:spaces/4ipcesaaaae  ← DM works

No agent:raa:googlechat:group:* sessions ever created for Space messages.
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Google Chat Space/Group messages are received (HTTP 200) but silently ignored; DMs work correctly. Tested with both Add-on and standard Chat API apps.

Steps to reproduce

  1. Configure Google Chat webhook with groupPolicy: "open" and audienceType: "app-url"
  2. Add the Chat app to a Space (group chat)
  3. Send a message mentioning @AppName in the Space
  4. Observe: HTTP 200 returned but no session created, no agent response
  5. Send a DM to the same app
  6. Observe: DM works correctly, session created as agent:X:googlechat:direct:spaces/Y

Expected behavior

Space messages should create sessions as agent:X:googlechat:group:spaces/Y and be processed by the agent, similar to how DMs create agent:X:googlechat:direct:spaces/Y sessions.

Actual behavior

Space messages return HTTP 200 but no session is created. No errors logged. The message is silently dropped. Caddy logs show the request was received and forwarded to gateway. OpenClaw logs show no googlechat:group session creation. Only googlechat:direct sessions appear (for DMs).

OpenClaw version

2026.3.28

Operating system

Ubuntu 24.04

Install method

npm global

Model

anthropic/claude-sonnet-4-6

Provider / routing chain

openclaw -> anthropic (direct)

Additional provider/model setup details

This is a Google Chat channel issue, not model-related. Config:

  • audienceType: "app-url"
  • groupPolicy: "open"
  • appPrincipal: configured
  • Tested with both Workspace Add-on format and standard Chat API app

Logs, screenshots, and evidence

Caddy access log (Space message received):
1774979423.83 200 /googlechat-raa-v2

OpenClaw sessions created (only DMs, no groups):
agent:raa:googlechat:direct:spaces/mlopdsaaaae  ← DM works
agent:raa:googlechat:direct:spaces/4ipcesaaaae  ← DM works

No agent:raa:googlechat:group:* sessions ever created for Space messages.

Impact and severity

Affected: Google Chat users trying to use Spaces (group chats) Severity: High (completely blocks group chat functionality) Frequency: 100% - all Space messages are ignored Consequence: Cannot use OpenClaw with Google Chat Spaces; only DMs work. Team collaboration via Spaces is blocked.

Additional information

Tested with two separate Google Cloud projects:

  1. App configured as Workspace Add-on (gcp-sa-gsuiteaddons service account)
  2. App configured as standard Chat API (unchecked "Create as Workspace Add-on")

Both have identical behavior: DMs work, Spaces don't.

Related issue #13856 describes similar symptoms but was attributed to Add-on format. This testing confirms the bug exists regardless of app configuration method.

Workaround: Use DMs only (works perfectly).

extent analysis

TL;DR

  • The issue may be resolved by adjusting the Google Chat webhook configuration, specifically the audienceType and groupPolicy settings, to correctly handle Space messages.

Guidance

  • Verify that the groupPolicy is set to "open" and audienceType is set to "app-url" in the Google Chat webhook configuration to ensure compatibility with Space messages.
  • Check the OpenClaw documentation to see if there are any specific requirements or settings for handling Google Chat Space messages.
  • Test the configuration with a different audienceType or groupPolicy setting to see if it affects the handling of Space messages.
  • Review the related issue #13856 to see if there are any additional insights or workarounds that may be applicable.

Example

  • No code snippet is provided as the issue seems to be related to configuration settings rather than code.

Notes

  • The issue seems to be specific to Google Chat Space messages and does not affect DMs.
  • The problem persists across different app configuration methods (Workspace Add-on and standard Chat API).

Recommendation

  • Apply workaround: Use DMs only until the issue with Space messages is resolved, as DMs are working correctly.

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…

FAQ

Expected behavior

Space messages should create sessions as agent:X:googlechat:group:spaces/Y and be processed by the agent, similar to how DMs create agent:X:googlechat:direct:spaces/Y sessions.

Still need to ship something?

×6

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

Back to top recommendations

TRENDING