Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.claw-link.dev/llms.txt

Use this file to discover all available pages before exploring further.

OpenClaw connection guide This is one of the classic messaging-platform traps: direct messages work, so you feel relieved for about five seconds. Then you try the real shared context you actually care about, and OpenClaw goes mysteriously quiet again. If OpenClaw works in DMs but not in groups or threads, the good news is that this usually means the core system is not dead. The bad news is that shared contexts add extra layers that direct chats do not:
  • mention and trigger rules
  • different permission scopes
  • thread visibility/access differences
  • channel-specific routing and behavior rules
  • more selective response expectations in shared spaces
This guide helps you isolate which of those is actually biting you.
Lightbulb icon Simple mental model: DMs prove the assistant can work somewhere. They do not prove it is configured to behave the same way in shared spaces.

Wrench icon At a glance

  • If DMs work, the issue is usually context-specific routing, permissions, or response rules.
  • Test with an explicit direct mention in the target group/thread before assuming the route is broken.
  • Compare one working DM flow against one failing group/thread flow side by side.

What this usually looks like

Users usually mean one of these:
  • OpenClaw replies in direct chat but ignores the same question in a group
  • it works in the main channel, but not inside threads
  • it is online in the server, but only DMs feel reliable
  • one shared space works, another does not
That usually points to route or context differences, not a total install failure.

Why DMs and groups behave differently

DMs are usually the easiest environment because:
  • there is only one participant path to consider
  • trigger conditions are simpler
  • permission scope is narrower and more obvious
  • there is less ambiguity about whether the assistant should respond
Groups and threads are messier because they introduce:
  • multiple participants
  • shared-space etiquette or response filtering
  • mention/addressing expectations
  • per-channel and per-thread visibility differences
So a DM success is good news, but it is not the final proof people think it is.

Fast troubleshooting flow

1) Test with an explicit direct mention in the group or thread

Before changing config, send the cleanest possible shared-context test:
  • one short prompt
  • explicitly addressed to the bot/assistant if that matters on the platform
  • in the exact group or thread you care about
This rules out the very common case where the bot was simply not expected to respond automatically there.

2) Check whether the bot can actually see that thread/group context

A bot can be healthy overall and still be unable to properly interact in one shared context. Check differences in:
  • group/channel access
  • thread visibility
  • reply/send permissions
  • mention handling or subscription scope
This matters especially when:
  • main channel works but thread does not
  • one group works but another does not

3) Compare the working DM path with the failing group/thread path

This is the fastest high-signal step. Compare:
  • target type
  • permissions
  • whether direct addressing is needed
  • whether the context is shared vs direct
  • whether the thread is newly created or restricted
If you do not compare them directly, you will end up debugging abstractions instead of differences.

4) Check whether silence is partly intentional in shared spaces

In some shared environments, OpenClaw should not respond to every low-signal message. That means ask:
  • was it actually addressed?
  • would a reply have been expected there?
  • is the system behaving selectively rather than failing?
This does not explain every issue, but it avoids misclassifying expected quiet behavior as breakage.

5) Check general runtime health after the context checks

Run:
openclaw status
openclaw gateway status --json
If DMs work and only group/thread contexts fail, global runtime health is less likely to be the main issue — but it is still worth confirming.

Common root causes

Root cause 1: mention or trigger mismatch

Symptoms:
  • DM works
  • group stays silent unless directly addressed
Fix:
  • test with explicit addressing in the shared context

Root cause 2: group/thread permissions problem

Symptoms:
  • DM works
  • one group or thread does not
Fix:
  • compare permissions and visibility directly

Root cause 3: thread-specific access issue

Symptoms:
  • main channel works
  • thread does not
Fix:
  • verify the bot can access and respond within that thread path

Root cause 4: route-specific config mismatch

Symptoms:
  • one shared context works, another fails
  • issue started after channel/config changes
Fix:
  • compare working vs failing route configuration

Root cause 5: expected selective silence misread as failure

Symptoms:
  • bot is quiet in low-signal group chatter
  • DM remains responsive
Fix:
  • test with an explicit, minimal, directed request

Practical checklist

Use this order:

1. Send one explicit direct mention in the failing group/thread

2. Compare the working DM path with the failing shared path

3. Check permissions and thread visibility

4. Check openclaw status

5. Check openclaw gateway status --json

6. Inspect route-specific config only after those comparisons

Final thought

When OpenClaw works in DMs but not in groups or threads, the system is usually telling you something useful:
  • the core assistant path works
  • the shared-context path does not
That means the right question is not “Why is OpenClaw broken?” It is “What is different about this shared context?” That question gets you to the fix much faster.
  • Connected Channel or Bot Is Online but OpenClaw Ignores Messages
  • Healthy Gateway, Wrong Routing: Why OpenClaw Isn’t Responding in the Channel You Expect
  • How to Run Multiple OpenClaw Bots or Agents in One Discord Setup