ClawGo Docs

English

简体中文

English

简体中文

Appearance

Channels Guide ​

Overview ​

ClawGo channel adapters live in pkg/channels. They bring external messages into the runtime and send runtime output back to the target platform.

Currently implemented channels include:

  • telegram
  • discord
  • feishu
  • dingtalk
  • qq
  • whatsapp
  • maixcam

The WebUI channel settings page now reflects the channels actually compiled into the current binary instead of always listing every possible adapter:

  • the full variant shows the full channel list
  • a single-channel build only shows that channel
  • the -nochannels / none build hides channel configuration pages entirely

The channel manager is responsible for:

  • initializing enabled adapters
  • starting and stopping them
  • delivering inbound messages into the bus
  • routing outbound messages by channel
  • applying dedupe windows and duplicate suppression

Common Settings ​

The exact fields vary by channel, but shared dedupe-related settings include:

  • inbound_message_id_dedupe_ttl_seconds
  • inbound_content_dedupe_window_seconds
  • outbound_dedupe_window_seconds

These settings control:

  • how long repeated inbound message IDs are ignored
  • whether repeated inbound content is treated as duplicate
  • whether repeated outbound sends are suppressed

Telegram ​

Telegram is one of the most common ways to start.

Common fields:

  • token
  • streaming
  • allow_from
  • allow_chats
  • enable_groups
  • require_mention_in_groups

Good for:

  • personal bots
  • small-group operational entry points
  • streaming replies

Feishu / DingTalk / QQ / Discord ​

The main differences across these channels are:

  • authentication style
  • allowed-origin fields
  • group vs direct-message constraints

But the integration model is the same:

  • inbound messages enter the runtime
  • outbound messages are pushed back through the message bus

WhatsApp ​

Recent versions treat WhatsApp more like a first-class bridge-backed channel service.

You can think about it in two ways:

  • use the default embedded bridge flow
  • explicitly configure channels.whatsapp.bridge_url

Common fields:

  • enabled
  • bridge_url
  • allow_from
  • enable_groups
  • require_mention_in_groups

If you use the WebUI channel settings page, you can also inspect:

  • bridge status
  • active account
  • recent bridge events
  • QR code availability

That makes it a better fit for phone-linked access, personal inbox entry points, or group-duty workflows.

MaixCam ​

maixcam is more device-oriented.

Common fields:

  • host
  • port
  • allow_from

This is more relevant for edge devices, camera workflows, or local hardware integrations.

Usage Advice ​

Start With One Channel ​

Start with a single channel such as Telegram and verify:

  • Gateway starts correctly
  • the token is valid
  • allow rules are correct
  • inbound messages reach a session

Tune Dedupe After That ​

If you later see:

  • webhook replays
  • repeated platform deliveries
  • duplicate outbound messages

then tune the dedupe settings.

Separate User And Ops Entry Points ​

If you use multiple channels, split:

  • user-facing entry points
  • operator-facing entry points

That keeps Cron, Sentinel, approvals, and normal user traffic from getting mixed together.