agent:main:main responds to Telegram DMs (duplicate replies)

[neon fjord]

agent:main:main session keeps sending replies to Telegram DMs alongside the telegram session. Every message gets two replies.

Tried: HEARTBEAT_OK in HEARTBEAT.md, heartbeat disable, removing deliveryContext from sessions.json — nothing works.

Filed GitHub issue #40005. Anyone know a workaround?

OpenClaw 2026.3.7 / macOS arm64

[drowsy drum]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[south relic]

Short version — two usual causes and three quick fixes.

Likely causes

• Two monitors/instances using the same Telegram bot token (eg. the daemon + the macOS app or two gateway processes) so each inbound update gets handled twice.
• OR the "main" session still has an active delivery route (deliveryContext / lastChannel / lastTo) so you get a per‑peer Telegram reply plus the main session replying as well.

Quick checks (what to run and what to look for)

1. Are there two gateways running?

   • openclaw gateway status
   • ps aux | rg openclaw
     If you see both a service + a foreground gateway, stop one.

2. Channel / monitor health

   • openclaw channels status --probe
     Confirm only one Telegram account is configured and healthy.

3. Inspect the session that’s duplicating

• openclaw sessions --json > /tmp/sessions.json
  • jq '.["agent:main:main"]' /tmp/sessions.json
    If you see deliveryContext / lastChannel / lastTo pointing at the Telegram peer, that explains why the main session is also sending.

4. Tail logs while reproducing (timestamp + duplicate deliveries)
   • openclaw logs --follow | rg -i 'telegram|route-reply|deliverReplies'
     Look for two delivery events with the same timestamps/session.

Workarounds (fast → more intrusive)

A — Fast, safe: block the main session from sending

• Easiest: open the Control UI (openclaw dashboard) → Sessions → open agent:main:main → set Send Policy = deny.
  • This prevents the main session from sending, keeping only the Telegram-per-peer session active.
  • No edit of files required; immediate and reversible.
• If you prefer config: you can also add a session.sendPolicy rule that denies the main key (restart required).

B — Manual (safe, needs restart): clear main session routing fields

(when the dashboard isn't convenient)

1. Stop the gateway:
   • openclaw gateway stop
2. Back up the store (adjust path if you have a custom store):
   • cp ~/.openclaw/agents/main/sessions/sessions.json ~/.openclaw/agents/main/sessions/sessions.json.bak
3. Remove the main route (example using jq):
   • cat ~/.openclaw/agents/main/sessions/sessions.json
     | jq 'del(.["agent:main:main"].deliveryContext, .["agent:main:main"].lastChannel, .["agent:main:main"].lastTo, .["agent:main:main"].lastAccountId, .["agent:main:main"].lastThreadId)' \

     /tmp/sessions.json && mv /tmp/sessions.json ~/.openclaw/agents/main/sessions/sessions.json

   • (If you don't have jq, open the file in an editor and remove those keys for the "agent:main:main" entry.)
4. Start the gateway:
   • openclaw gateway start
5. Verify with openclaw sessions --json and repro.

C — Longer-term: change DM scoping (if main session should not own DMs)

• If you want DMs to be per-peer sessions (so the main session is not used), set dmScope to per-channel-peer:
  • openclaw config set session.dmScope "per-channel-peer" (then restart gateway)

• Note: changing dmScope is a behavior/config change — test it first.

If it’s actually two monitors (same token)

• Make sure you don’t have two processes using the same bot token (macOS app + daemon, or two gateway installs).
• Stop one instance (or use different tokens/accounts).

If none of the above fixes it

• Capture these and paste them in the GitHub issue or here so I can look:
  • output of openclaw sessions --json (redact phone numbers if you want)
  • a short snippet of openclaw logs --follow around the duplicate deliveries (timestamps)
  • openclaw gateway status
    I’ll inspect the logs/session JSON and point to the exact field that’s causing the duplicate.

If you want, tell me:

• whether you run the mac app + daemon
• the exact path you use for the session store (or run openclaw config get session.store)
  and I can give the exact jq/sed commands to fix it quickly.

[neon fjord]

"Tried all three options. A (Send Policy) not available in dashboard UI. B (clearing deliveryContext) — fields were already empty in agent:main:main. C (dmScope per-channel-peer) — applied but still getting duplicate replies. Any other suggestions?"

[south relic]

If agent:main:main has no deliveryContext and no lastChannel/lastTo, and switching session.dmScope didn’t change anything, then this is almost certainly not “main session delivery routing”.

At that point, the consistent explanation for “every Telegram DM gets two bot replies” is:

1) You have two OpenClaw instances consuming the same Telegram bot token

Common ways this happens on macOS:

• Gateway is running as a LaunchAgent service and you also have a second gateway running somewhere else (old laptop/VPS).
• Config mismatch: you edited the config your CLI uses, but the service is running with a different OPENCLAW_STATE_DIR / config file (so your dmScope change didn’t actually affect the instance that’s replying).

What to check (these 3 outputs will usually reveal it):

1. Service vs CLI config mismatch

openclaw gateway status

Look specifically for lines like “Config (cli)” vs “Config (service)” (paths).
If they differ, your changes are going to the wrong place. Fix is usually:

openclaw gateway install --force
openclaw gateway restart

(That forces the LaunchAgent to point at the same config/state the CLI is using.)

2. Do you accidentally have multiple Telegram accounts configured?

openclaw config get channels.telegram.accounts

If you see more than one account, make sure you didn’t duplicate the same bot token across accounts (that can produce “double replies”).

3. Telegram getUpdates conflict clue

openclaw logs --follow | rg -i "telegram|getupdates|409|conflict"

If you see 409/getUpdates conflict messages, Telegram is telling you “more than one bot instance is running”.