DEV Community: Asim Hayat

OpenClaw WhatsApp: How to Lock Your Bot to One Specific Group

Asim Hayat — Sat, 07 Mar 2026 02:41:06 +0000

The first time I added OpenClaw to a WhatsApp group, it replied to every single message. My friend sent "lol" and the bot wrote a three-paragraph response. Someone shared a meme and it started analyzing the image. My phone was blowing up.

Then people started DMing my number directly because OpenClaw uses your WhatsApp account, not a separate bot number. The bot was happily chatting with complete strangers.

I turned it off within 10 minutes.

The fix took another 10 minutes once I figured out the config. Here's exactly how to lock your OpenClaw bot so it only responds in one specific group, only when mentioned, and ignores everything else.

The Problem: OpenClaw Talks to Everyone

OpenClaw doesn't have its own WhatsApp number. It piggybacks on yours. That means every DM to your number hits the bot, every group you're in becomes a potential chat room, and the bot eats API tokens on messages you never wanted it to see.

If you're running Anthropic's API, that "lol" response probably cost you $0.02. Multiply that by 50 messages in an active group and you're burning through credits for nothing.

The config file that controls all of this lives at ~/.openclaw/openclaw.json. Every change requires a restart:

openclaw restart

Let's lock it down layer by layer.

Layer 1: Lock DMs With allowFrom

First, stop random people from chatting with your bot. The allowFrom field controls who can send DMs:

{
  "channels": {
    "whatsapp": {
      "allowFrom": ["+15551234567"]
    }
  }
}

Only numbers in this array can DM the bot. Everyone else gets ignored. No response, no error message, nothing. The bot just silently drops the message.

Use full international format with the + prefix. If you want to add a second person:

"allowFrom": ["+15551234567", "+15559876543"]

Quick tip: if you don't want to hardcode numbers, use dmPolicy: "pairing" instead. This makes unknown senders receive a pairing code that you have to approve before they can chat:

{
  "channels": {
    "whatsapp": {
      "dmPolicy": "pairing",
      "allowFrom": ["+15551234567"]
    }
  }
}

Pairing requests expire after 1 hour and are capped at 3 pending requests per channel, so nobody can flood your bot with approval requests.

Layer 2: Set Group Policy

Now for groups. OpenClaw has two independent filtering layers for groups, and this is where most people get confused.

groupPolicy controls who can trigger the bot in groups. The groups block controls which groups the bot responds in. They work together but they're configured separately.

Start with groupPolicy. You have two options:

"allowlist" means only senders listed in groupAllowFrom can trigger the bot in any group:

{
  "channels": {
    "whatsapp": {
      "groupPolicy": "allowlist",
      "groupAllowFrom": ["+15551234567"]
    }
  }
}

"open" means anyone in an allowed group can trigger the bot (with mention gating):

{
  "channels": {
    "whatsapp": {
      "groupPolicy": "open"
    }
  }
}

Which one should you use? If it's a personal bot and only you should trigger it, go with "allowlist" and put your number in groupAllowFrom. If it's a team or client bot where multiple people need access, use "open" and rely on group-level controls plus mention gating.

Layer 3: Target One Specific Group

This is the part everyone wants. You need the group's JID (Jabber ID), which looks like 120363407119785089@g.us.

To find your group JID, run this command and then send a message in the target group:

openclaw logs --follow

Watch the logs for a line like:

Inbound message 120363407119785089@g.us -> +15551234567 (group)

That long number before @g.us is your group JID. Copy it.

Now configure the groups block to only allow that specific group:

{
  "channels": {
    "whatsapp": {
      "dmPolicy": "pairing",
      "allowFrom": ["+15551234567"],
      "groupPolicy": "open",
      "groups": {
        "120363407119785089@g.us": {
          "requireMention": true
        }
      }
    }
  }
}

When the groups block exists and doesn't include a "*" wildcard, it acts as an allowlist. Only the groups listed here will get responses. Every other group is silently ignored.

Setting requireMention: true means someone has to @mention the bot or reply to one of its messages before it responds. Without this, the bot replies to every message in the group.

If you want the bot to reply to everything in that one group without needing a mention:

"120363407119785089@g.us": {
  "requireMention": false
}

Only do this for small, private groups. In a 50-person group with requireMention: false, your API bill will be ugly.

The Full Config: One Group, Locked Down

Here's the complete config that locks DMs, targets one group, and requires mentions:

{
  "channels": {
    "whatsapp": {
      "dmPolicy": "pairing",
      "allowFrom": ["+15551234567"],
      "groupPolicy": "open",
      "groups": {
        "120363407119785089@g.us": {
          "requireMention": true
        }
      },
      "ackReaction": {
        "emoji": "👀",
        "direct": true,
        "group": "mentions"
      },
      "sendReadReceipts": true
    }
  },
  "agents": {
    "list": [
      {
        "id": "main",
        "groupChat": {
          "mentionPatterns": ["@openclaw", "openclaw", "@bot"],
          "historyLimit": 50
        }
      }
    ]
  }
}

Let me break down the extras.

ackReaction makes the bot react with 👀 when it receives your message, so you know it's processing. In groups, it only reacts on mentions.

sendReadReceipts shows the blue ticks so you know the bot read the message.

mentionPatterns is the list of words that trigger the bot in groups. Add whatever your team will naturally type. Replying to a bot message also counts as a mention automatically.

historyLimit: 50 means the bot sees the last 50 messages in the group for context, even ones it didn't respond to. Useful for "catch up" questions like "summarize what everyone said."

Known Bug: groupPolicy "allowlist" Can Block Everything

Here's something that tripped me up and has caught others too. If you use groupPolicy: "allowlist" but leave groupAllowFrom empty, all group messages are blocked even if you've configured specific groups in the groups block.

This happens because OpenClaw checks groupAllowFrom first. If it's empty, the message is dropped before it ever reaches the group-level config.

There's an open GitHub issue (#6558) about this. The workaround is simple: use groupPolicy: "open" and let the groups block handle which groups are allowed. That's what I use in my config above.

If you specifically need sender-level filtering in groups where only certain people can trigger the bot, you need to set both:

{
  "groupPolicy": "allowlist",
  "groupAllowFrom": ["+15551234567", "+15559876543"],
  "groups": {
    "120363407119785089@g.us": {
      "requireMention": true
    }
  }
}

Testing It

After saving your config and running openclaw restart, test each layer:

1. DM test. Have a friend who is not in your allowFrom list DM your WhatsApp number. The bot should not respond.

2. Wrong group test. Send a message in a group that is not in your groups config. The bot should ignore it.

3. Right group, no mention. Send a normal message in the target group without mentioning the bot. If requireMention is true, the bot should stay quiet. The message still gets stored for context though.

4. Right group, with mention. Send "@openclaw what's the weather?" in the target group. The bot should respond.

5. Check logs. Run openclaw logs --follow and watch for:

Blocked group message (group not in allowlist)

Skipped (no mention)

These confirm each layer is working.

6. Run the doctor.

openclaw doctor

This surfaces risky or misconfigured DM policies and group settings. If anything looks off, it'll tell you.

Quick Reference

What you want	Config
Only I can DM the bot	`allowFrom: ["+1555..."]`
Unknown people get pairing flow	`dmPolicy: "pairing"`
Bot only active in one group	`groups: { "JID@g.us": { ... } }` (no `"*"` entry)
Bot requires @mention in group	`requireMention: true`
Anyone in the group can trigger	`groupPolicy: "open"`
Only specific people can trigger	`groupPolicy: "allowlist"` + `groupAllowFrom`
Bot reacts when processing	`ackReaction: { emoji: "👀" }`

What's Next

In the next article, I'll cover how to switch AI models in OpenClaw without losing your conversation history. Useful when you want Claude for complex tasks and Gemini Flash for quick replies to save on API costs.

Need Help Setting This Up?

I deploy and maintain OpenClaw professionally. AWS, Docker, Nginx, Telegram, WhatsApp, multi-agent, the works.

150+ projects delivered. 100% job success rate. Top Rated Plus on Upwork.

→ Hire me on Upwork → Email: chaudhryasim5@gmail.com

Stop Exposing Port 18789: How I Secure OpenClaw on AWS EC2 with Nginx and SSL

Asim Hayat — Sat, 28 Feb 2026 01:09:27 +0000

I've set up OpenClaw on EC2 multiple times now — for myself and for clients. And every single time I take over someone else's setup, I find the same thing: port 18789 wide open to the internet, no SSL, no reverse proxy, running as root.

Bitsight found over 30,000 exposed OpenClaw instances. Attackers aren't even bothering with prompt injection — they're connecting directly to the gateway WebSocket and getting full access.

This is how I deploy OpenClaw properly. Gateway on loopback, Nginx in front, SSL via Let's Encrypt, and EC2 security groups that only allow what's necessary. Takes about 30 minutes.

Why 0.0.0.0 Binding Will Get You Hacked

When you run through OpenClaw's onboarding wizard, it asks you about the gateway bind mode. A lot of people pick "LAN" because they want to access the dashboard from their browser. That binds the gateway to 0.0.0.0 — meaning every network interface on the machine.

On an EC2 instance, that means anyone on the internet can hit port 18789 directly. Your gateway is now a public endpoint. Even with token auth enabled, you're one misconfiguration away from someone controlling your AI agent, reading your sessions, and executing commands on your server.

The OpenClaw docs are clear about this: never expose the gateway unauthenticated on 0.0.0.0.

Here's what we're going to do instead:

Internet → Port 443 (HTTPS) → Nginx → 127.0.0.1:18789 → OpenClaw Gateway

The gateway only talks to localhost. Nginx handles SSL termination and proxies requests. Nothing else is exposed.

Prerequisites

An AWS EC2 instance running Ubuntu 24.04 (t3.medium or bigger — OpenClaw needs at least 4GB RAM for comfortable operation)
A domain name pointed to your EC2 instance's public IP (I'll use openclaw.yourdomain.com as an example)
SSH access to your instance
An API key from your LLM provider (Anthropic, OpenAI, Gemini, etc.)

Step 1: Install OpenClaw

SSH into your EC2 instance and install OpenClaw:

# Make sure Node 22+ is installed
node --version

# Install OpenClaw
curl -fsSL https://openclaw.ai/install.sh | bash

# Run the onboarding wizard
openclaw onboard --install-daemon

During onboarding, when it asks about the gateway bind mode, pick loopback. This is critical. It binds the gateway to 127.0.0.1 only.

If you've already set up OpenClaw with a different bind mode, fix it:

openclaw config set gateway.bind loopback

Verify it's running:

openclaw gateway status

You should see the gateway running on 127.0.0.1:18789. If you try to access http://your-ec2-ip:18789 from your browser right now, it should refuse the connection. That's exactly what we want.

Step 2: Set Up Gateway Authentication

Even though we're binding to loopback, set up token auth. Defense in depth:

# Generate a strong random token
TOKEN=$(openssl rand -hex 32)
echo "Your gateway token: $TOKEN"
echo "Save this somewhere safe."

# Set the token
openclaw config set gateway.auth.mode token
openclaw config set gateway.auth.token "$TOKEN"

Also configure trusted proxies so OpenClaw correctly reads the real client IP from Nginx:

openclaw config set gateway.trustedProxies '["127.0.0.1"]'

Without this, OpenClaw sees Nginx's IP for every request instead of the actual client IP. That breaks rate limiting and IP-based access controls.

Restart the gateway to apply changes:

sudo systemctl restart openclaw

Step 3: Install and Configure Nginx

sudo apt update
sudo apt install -y nginx

Create the Nginx config for OpenClaw:

sudo nano /etc/nginx/sites-available/openclaw

Paste this:

upstream openclaw_gateway {
    server 127.0.0.1:18789;
}

server {
    listen 80;
    server_name openclaw.yourdomain.com;

    # Redirect all HTTP to HTTPS (we'll set up SSL next)
    location / {
        return 301 https://$server_name$request_uri;
    }
}

server {
    listen 443 ssl http2;
    server_name openclaw.yourdomain.com;

    # SSL certs will be added by Certbot in the next step
    # ssl_certificate /etc/letsencrypt/live/openclaw.yourdomain.com/fullchain.pem;
    # ssl_certificate_key /etc/letsencrypt/live/openclaw.yourdomain.com/privkey.pem;

    location / {
        proxy_pass http://openclaw_gateway;
        proxy_http_version 1.1;

        # WebSocket support — required for OpenClaw dashboard
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        # Pass real client IP to OpenClaw
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Host $host;

        # Longer timeouts for WebSocket connections
        proxy_read_timeout 86400;
        proxy_send_timeout 86400;
    }
}

Replace openclaw.yourdomain.com with your actual domain.

Enable the site and test the config:

sudo ln -s /etc/nginx/sites-available/openclaw /etc/nginx/sites-enabled/
sudo rm /etc/nginx/sites-enabled/default  # Remove default site
sudo nginx -t
sudo systemctl reload nginx

If nginx -t shows errors, fix them before moving on. Don't skip this.

Step 4: SSL with Let's Encrypt

Install Certbot and get your certificate:

sudo apt install -y certbot python3-certbot-nginx

sudo certbot --nginx -d openclaw.yourdomain.com

Certbot will ask for your email, agree to terms, and then automatically modify your Nginx config to add the SSL certificate paths. It also sets up auto-renewal.

Verify auto-renewal works:

sudo certbot renew --dry-run

Now uncomment the SSL lines in your Nginx config (Certbot usually does this automatically, but double-check):

sudo nginx -t
sudo systemctl reload nginx

Test it: open https://openclaw.yourdomain.com in your browser. You should see the OpenClaw Control UI with a valid SSL certificate and no browser warnings.

Step 5: Configure OpenClaw for the Reverse Proxy

Since we're accessing the Control UI through a domain now (not localhost), OpenClaw needs to know about the allowed origin:

openclaw config set gateway.controlUi.allowedOrigins '["https://openclaw.yourdomain.com"]'

Watch out for a known gotcha: if you see an error about controlUI (capital UI), ignore that — the correct config key uses lowercase controlUi. This is a known bug in the error message as of version 2026.2.24.

Restart the gateway:

sudo systemctl restart openclaw

Step 6: systemd Service with Auto-Restart

If you used openclaw onboard --install-daemon, systemd should already be configured. But let's make sure it's set up properly for production:

sudo nano /etc/systemd/system/openclaw.service

It should look something like this:

[Unit]
Description=OpenClaw Gateway
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=ubuntu
Environment=NODE_ENV=production
ExecStart=/usr/local/bin/openclaw gateway --port 18789
Restart=always
RestartSec=10
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

Key settings:

Restart=always — if it crashes, systemd brings it back
RestartSec=10 — waits 10 seconds before restart (avoids crash loops)
User=ubuntu — don't run as root

Enable and start:

sudo systemctl daemon-reload
sudo systemctl enable openclaw
sudo systemctl start openclaw

Verify it's running:

sudo systemctl status openclaw
journalctl -u openclaw -f  # Live logs

After a server reboot, OpenClaw will start automatically. Test this by running sudo reboot and checking after the instance comes back up.

Step 7: Lock Down EC2 Security Groups

Go to your AWS Console → EC2 → Security Groups → select the group attached to your instance.

Set inbound rules to:

Port	Protocol	Source	Why
22	TCP	Your IP only	SSH access
80	TCP	0.0.0.0/0	HTTP → redirects to HTTPS
443	TCP	0.0.0.0/0	HTTPS (Nginx + SSL)

That's it. Three ports. Everything else is blocked.

Specifically, make sure port 18789 is NOT in your security group rules. There's zero reason for it to be accessible from the internet since Nginx proxies everything through 443.

If you want to be extra careful with SSH, restrict port 22 to only your IP address instead of 0.0.0.0/0. You can find your IP at whatismyip.com.

Final Checklist

Run through this before you call it done:

[ ] openclaw gateway status shows running on 127.0.0.1:18789
[ ] curl http://localhost:18789 from the server returns a response
[ ] curl http://YOUR_EC2_PUBLIC_IP:18789 from your laptop returns connection refused
[ ] https://openclaw.yourdomain.com loads the dashboard with valid SSL
[ ] WebSocket connection works (dashboard is interactive, not just static)
[ ] sudo systemctl status openclaw shows active
[ ] sudo reboot → wait → OpenClaw comes back automatically
[ ] EC2 security group only has ports 22, 80, 443
[ ] openclaw security audit runs clean (or with only expected warnings)

What This Setup Looks Like

Internet
    │
    ▼
┌──────────────────────┐
│  EC2 Security Group  │
│  Only 22, 80, 443    │
└──────────┬───────────┘
           │
           ▼
┌──────────────────────┐
│     Nginx (:443)     │
│  SSL termination     │
│  WebSocket proxy     │
└──────────┬───────────┘
           │ proxy_pass
           ▼
┌──────────────────────┐
│  OpenClaw Gateway    │
│  127.0.0.1:18789     │
│  Token auth enabled  │
└──────────────────────┘

No exposed ports. SSL everywhere. Auto-restart on crash or reboot. Gateway only talks to localhost.

This is the same setup I run for myself and deploy for clients. Nothing fancy, just proper infrastructure that doesn't leave your AI agent exposed to the internet.

Need Help Setting This Up?

I deploy and maintain OpenClaw professionally — AWS, Docker, Nginx, Telegram, WhatsApp, multi-agent, the works.

150+ projects delivered. 100% job success rate. Top Rated Plus on Upwork.

→ Hire me on Upwork
→ Email: chaudhryasim5@gmail.com