openclaw - 💡(How to fix) Fix [Bug]: Google Chat inbound webhook broken in v2026.3.24 (google-auth-library downgrade regression) [1 comments, 1 participants]

Summary

Google Chat inbound webhook processing is broken in v2026.3.24. The channel starts without errors and the webhook endpoint accepts requests (returns 401 for invalid JWTs), but no inbound messages from Google Chat spaces or DMs are processed. Downgrading to v2026.3.13 immediately restores functionality with the same configuration.

Steps to reproduce

1. Run OpenClaw v2026.3.13 with Google Chat configured (webhook mode, audienceType: "app-url")
2. Confirm Google Chat inbound messages work (DMs and spaces)
3. Update to v2026.3.24 (npm install -g [email protected])
4. Restart the gateway
5. Google Chat inbound messages stop being processed — zero log entries for incoming messages
6. Downgrade back to v2026.3.13 — immediately works again

Expected behavior

Google Chat inbound webhook messages should be received and processed identically to v2026.3.13.

Actual behavior

• Channel starts normally: [googlechat] [default] starting Google Chat webhook — no errors
• Webhook endpoint is live and returns HTTP 401 for unauthenticated test POSTs (correct)
• But real Google Chat messages produce zero log output — no auth errors, no processing, complete silence
• Outbound messaging (sending TO Google Chat via the message tool) works fine on v2026.3.24

Root cause investigation

I traced the regression to a google-auth-library version change between releases:

Key findings:

1. v2026.3.24 downgraded google-auth-library from 10.6.2 to 9.15.1 — this older version brings its own nested [email protected] under node_modules/google-auth-library/node_modules/gaxios/

2. The gaxios-fetch-compat layer only patches the top-level [email protected] (resolved via createRequire(import.meta.url).resolve("gaxios")). The nested [email protected] inside google-auth-library is never patched, which may cause silent JWT verification failures.

3. Manually upgrading google-auth-library to 10.6.2 inside v2026.3.24's node_modules causes an OOM crash (RegExp compilation failure), indicating the bundled code has hard assumptions about the 9.15.1 API surface.

4. In v2026.3.13, [email protected] uses the shared top-level gaxios (no nested copy), so the compat layer covers all fetch paths.

Environment

• OpenClaw version: 2026.3.24 (broken) / 2026.3.13 (working)
• OS: Debian 14 (Linux 6.19.8, x64)
• Node.js: v22.22.1
• Install method: npm global
• Google Chat config:

{
  "googlechat": {
    "enabled": true,
    "webhookPath": "/googlechat",
    "audienceType": "app-url",
    "audience": "https://example.com/googlechat",
    "serviceAccountFile": "/path/to/service-account.json"
  }
}

• Webhook delivery: via Cloudflare Tunnel (same tunnel config works on v2026.3.13)

Impact

• Severity: High — complete loss of Google Chat inbound messaging
• Affected: All Google Chat webhook users on v2026.3.24
• Workaround: Pin to v2026.3.13 (npm install -g [email protected])

Related issues

• #23402 — Google Chat silent crash-loop (v2026.2.21, abortSignal — different root cause)
• #13856 — Space webhook events not received (v2026.2.9 — different root cause)
• #33370 — DM replies create threads (v2026.3.2 — replyToMode — different issue)

Suggested fix

Either:

1. Upgrade google-auth-library back to 10.x in the v2026.3.25 dependency tree
2. Extend installGaxiosFetchCompat() to also patch nested gaxios instances (e.g. walk node_modules or hook require/import)
3. Ensure the bundled Google Chat extension code is compatible with [email protected]