openclaw - 💡(How to fix) Fix [Feature]: googlechat — add `dm.threadReplies` config option to control reply threading [1 participants]

Summary

Add a dm.threadReplies config option to the Google Chat channel so replies can be sent as top-level messages in the DM space rather than nested thread replies.

Problem to solve

When a user sends a DM to a Google Chat app powered by OpenClaw, the bot's reply always appears in a thread under the original message rather than as a top-level message in the DM chat body.

This happens because channel.runtime hardcodes thread: payload.replyToId (derived from the inbound message.thread.name) in every reply call — both for the typing indicator message and the actual response. There is no config option to suppress this.

The result: the user sees their message in the main DM chat, but has to click into a thread to see the bot's reply — a poor UX for a conversational assistant.

Notably, proactive sends (where the bot initiates a message) already work correctly — they appear in the main chat body because no thread param is set. The fix for replies is the same: simply omit thread from the sendGoogleChatMessage call when threading is disabled.

Proposed solution

Add a replyToMode config option to channels.googlechat (matching the Matrix channel's existing threadReplies field):

"googlechat": {
  "replyToMode": "off"
}

Enum values:

• "off" — never thread replies; all replies go to the main DM chat body
• • "inbound" — thread replies only when the inbound message has a thread (current default behavior)
• • • "always" — always thread replies Default: "inbound" (preserves backward compatibility — existing configs without this key behave exactly as they do today)

Implementation: In sendGoogleChatMessage, the thread param is already conditional (if (thread) body.thread = { name: thread }). When replyToMode is "off", simply don't pass the thread argument from payload.replyToId. No changes needed to the send function itself — only the call site in the reply handler.

Alternatives considered

1. Monkey-patching the OpenClaw source — fragile, breaks on every update, unsupported.
2. 1. System prompt instruction to never thread — Pixel cannot control the OpenClaw runtime's outbound call; the threading is applied by the gateway layer after the LLM response, not by the agent itself.
3. 1. Using a separate outbound-only bot — high operational complexity; defeats the purpose of a unified channel config.
4. 1. Doing nothing / user clicks into thread — UX regression; every DM conversation requires an extra tap to read replies, which is disruptive for a conversational assistant.

Impact

• Affected: All users running Google Chat apps via OpenClaw in DM mode
• • Severity: Medium — app is functional but UX is degraded; users must click into a thread to read every reply
• • • Frequency: Every single DM interaction
• • • • Consequence: Conversational AI assistants feel unnatural in Google Chat DMs; replies are hidden behind a thread click rather than appearing inline in the conversation

Evidence/examples

Code location: channel.runtime-CBZ9BGA0.js

The typing indicator send (hardcoded thread):

typingMessageName = (await sendGoogleChatMessage({
  account, space: spaceId,
  text: `_${botName} is typing..._`,
  thread: message.thread?.name   // ← always threaded
}))?.messageName;

The reply delivery (hardcoded thread):

await sendGoogleChatMessage({
  account, space: spaceId,
  text: chunk,
  thread: payload.replyToId   // ← always threaded
});

sendGoogleChatMessage already conditionally includes the thread (if (thread) body.thread = { name: thread }), so omitting it when threadReplies: "off" requires no changes to that function.

Precedent: Matrix channel config schema already defines:

threadReplies: z.enum(["off", "inbound", "always"]).optional()

The identical pattern is requested for Google Chat.

Additional information

• OpenClaw version: 2026.4.2
• • Channel: googlechat (single-account mode)
• • • Platform: Windows, running as a local gateway with Cloudflare Tunnel
• • • • The fix must remain backward-compatible — existing configs without replyToMode should continue to thread replies (current behavior)
• • • • • replyToMode: "off" is the primary use case requested; "first" and "all" variants would align with Matrix parity
• • • • • • The typingIndicator field already scopes per-account cleanly; replyToMode should follow the same pattern