Summary
In OpenClaw 2026.2.23, setting dmPolicy: "allowlist" (or groupPolicy: "allowlist") on Telegram or Matrix accounts silently drops all inbound messages instead of applying the allowlist or inheriting from the top-level channel config. The same bug was fixed in the same release for WhatsApp (#24670) and Slack (#17579) but the fix was not applied to the Telegram and Matrix providers.
Workaround: Switch dmPolicy to pairing or open. Both work correctly.
Environment
OpenClaw version: 2026.2.23 (b817600)
OS: Linux 6.12.0-124.28.1.el10_1.x86_64 (x64)
Node: 22.22.0
Install method: pnpm (npm package, not git checkout)
Channels affected: Telegram, Matrix
Channels not affected: WhatsApp (fixed in #24670), Slack (fixed in #17579), Webchat (unaffected)
Steps to reproduce
Configure one or more Telegram or Matrix accounts with dmPolicy: "allowlist" and either an empty allow array or relying on top-level channels.telegram.dmPolicy/channels.matrix.dm.policy inheritance.
Start the gateway.
Send a DM to any of the affected bot accounts.
Expected: Message is processed (if sender is on the allowlist) or rejected with a policy message (if not).
Actual: Message is silently dropped. Nothing appears in logs. No session is created.
Minimal Reproducing Config
Telegram
json
{
"channels": {
"telegram": {
"enabled": true,
"dmPolicy": "allowlist",
"accounts": {
"atlas": {
"enabled": true,
"dmPolicy": "allowlist",
"botToken": "..."
}
}
}
}
}
Sending a DM to the atlas bot produces no log output and no session entry.
Matrix
json
{
"channels": {
"matrix": {
"enabled": true,
"homeserver": "https://matrix.example.com",
"dm": {
"policy": "allowlist",
"allow": ["@user:matrix.example.com"]
},
"accounts": {
"atlas": {
"userId": "@atlas:matrix.example.com",
"accessToken": "...",
"enabled": true
}
}
}
}
}
Sending a Matrix DM to @atlas:matrix.example.com produces no log output and no session entry. The top-level dm.allow list is not inherited.
Expected behavior
If the sender is on the allow list: message is dispatched to the agent, a session is created, and the agent replies.
If the sender is not on the allow list: message is rejected with a policy response (e.g. "You are not allowed to interact with this bot.").
If no per-account allow list is set: policy and allow list are inherited from the top-level channels.telegram.dmPolicy / channels.matrix.dm config.
In all cases, the gateway logs the inbound message at the channel level regardless of whether it is accepted or rejected.
Actual behavior
Inbound messages are silently dropped for all accounts with dmPolicy: "allowlist".
Nothing appears in the gateway logs when a message is sent — not even a raw channel event.
No session is created.
The sender receives no response and no rejection notice.
openclaw channels status --probe and openclaw status --deep both report all accounts as OK, giving no indication that anything is wrong.
Top-level dm.allow is not inherited by per-account configs.
OpenClaw version
2026.2.23
Operating system
Rocky Linux 10
Install method
No response
Logs, screenshots, and evidence
Impact and severity
No response
Additional information
Additional Observations
Only explicit room IDs work for Matrix
The only Matrix configuration that works correctly is an account with an explicit room ID listed under groups:
json
"panoptes": {
"userId": "@panoptes:matrix.example.com",
"accessToken": "...",
"enabled": true,
"groupPolicy": "allowlist",
"groups": {
"!RoomId:matrix.example.com": {
"allow": true,
"requireMention": false
}
}
}
Messages to that specific room are received and dispatched correctly. DMs to the same account are not, regardless of dm.policy setting.
Policy path vs. explicit ID path
This suggests the dm policy enforcement code path is broken entirely in 2026.2.23 for both Telegram and Matrix, while the explicit room/chat ID lookup path is unaffected.
Delivery recovery also broken
The gateway startup log shows a related issue:
text
[delivery-recovery] Found 25 pending delivery entries — starting recovery
[delivery-recovery] Recovery time budget exceeded — 25 entries deferred to next restart
[delivery-recovery] Delivery recovery complete: 0 recovered, 0 failed, 0 skipped
This completes in ~8ms, suggesting the time budget check itself is failing instantly. The 25 entries are deferred to next restart but reproduce the same instant timeout on every restart, effectively making them unrecoverable without manual intervention.
Workaround
Switch dmPolicy from allowlist to pairing on all affected accounts. Both Telegram and Matrix begin dispatching messages correctly:
bash
Telegram
for account in atlas panoptes apollo athena hestia theseus; do
openclaw config set channels.telegram.accounts.$account.dmPolicy pairing
done
Matrix
for account in atlas apollo athena hestia theseus chronos midas; do
openclaw config set channels.matrix.accounts.$account.dm '{"policy":"pairing"}'
done
openclaw gateway restart
Setting dmPolicy: "open" also works. The issue is specific to the allowlist enforcement path.
Related Issues
#24670 — WhatsApp/Group policy: fix groupAllowFrom sender filtering when groupPolicy: "allowlist" is set without explicit groups (same bug, fixed for WhatsApp in this release)
#17579 — Slack/Group policy: fix multi-account groupPolicy inheritance (same bug, fixed for Slack in this release)
The fix for Telegram and Matrix should mirror what was done for WhatsApp (#24670) — fall back to top-level channel policy when a per-account allowlist has no explicit allow entries, rather than silently dropping all messages.
Summary
In OpenClaw 2026.2.23, setting dmPolicy: "allowlist" (or groupPolicy: "allowlist") on Telegram or Matrix accounts silently drops all inbound messages instead of applying the allowlist or inheriting from the top-level channel config. The same bug was fixed in the same release for WhatsApp (#24670) and Slack (#17579) but the fix was not applied to the Telegram and Matrix providers.
Workaround: Switch dmPolicy to pairing or open. Both work correctly.
Environment
OpenClaw version: 2026.2.23 (b817600)
OS: Linux 6.12.0-124.28.1.el10_1.x86_64 (x64)
Node: 22.22.0
Install method: pnpm (npm package, not git checkout)
Channels affected: Telegram, Matrix
Channels not affected: WhatsApp (fixed in #24670), Slack (fixed in #17579), Webchat (unaffected)
Steps to reproduce
Configure one or more Telegram or Matrix accounts with dmPolicy: "allowlist" and either an empty allow array or relying on top-level channels.telegram.dmPolicy/channels.matrix.dm.policy inheritance.
Start the gateway.
Send a DM to any of the affected bot accounts.
Expected: Message is processed (if sender is on the allowlist) or rejected with a policy message (if not).
Actual: Message is silently dropped. Nothing appears in logs. No session is created.
Minimal Reproducing Config
Telegram
json
{
"channels": {
"telegram": {
"enabled": true,
"dmPolicy": "allowlist",
"accounts": {
"atlas": {
"enabled": true,
"dmPolicy": "allowlist",
"botToken": "..."
}
}
}
}
}
Sending a DM to the atlas bot produces no log output and no session entry.
Matrix
json
{
"channels": {
"matrix": {
"enabled": true,
"homeserver": "https://matrix.example.com",
"dm": {
"policy": "allowlist",
"allow": ["@user:matrix.example.com"]
},
"accounts": {
"atlas": {
"userId": "@atlas:matrix.example.com",
"accessToken": "...",
"enabled": true
}
}
}
}
}
Sending a Matrix DM to @atlas:matrix.example.com produces no log output and no session entry. The top-level dm.allow list is not inherited.
Expected behavior
If the sender is on the allow list: message is dispatched to the agent, a session is created, and the agent replies.
If the sender is not on the allow list: message is rejected with a policy response (e.g. "You are not allowed to interact with this bot.").
If no per-account allow list is set: policy and allow list are inherited from the top-level channels.telegram.dmPolicy / channels.matrix.dm config.
In all cases, the gateway logs the inbound message at the channel level regardless of whether it is accepted or rejected.
Actual behavior
Inbound messages are silently dropped for all accounts with dmPolicy: "allowlist".
Nothing appears in the gateway logs when a message is sent — not even a raw channel event.
No session is created.
The sender receives no response and no rejection notice.
openclaw channels status --probe and openclaw status --deep both report all accounts as OK, giving no indication that anything is wrong.
Top-level dm.allow is not inherited by per-account configs.
OpenClaw version
2026.2.23
Operating system
Rocky Linux 10
Install method
No response
Logs, screenshots, and evidence
Impact and severity
No response
Additional information
Additional Observations
Only explicit room IDs work for Matrix
The only Matrix configuration that works correctly is an account with an explicit room ID listed under groups:
json
"panoptes": {
"userId": "@panoptes:matrix.example.com",
"accessToken": "...",
"enabled": true,
"groupPolicy": "allowlist",
"groups": {
"!RoomId:matrix.example.com": {
"allow": true,
"requireMention": false
}
}
}
Messages to that specific room are received and dispatched correctly. DMs to the same account are not, regardless of dm.policy setting.
Policy path vs. explicit ID path
This suggests the dm policy enforcement code path is broken entirely in 2026.2.23 for both Telegram and Matrix, while the explicit room/chat ID lookup path is unaffected.
Delivery recovery also broken
The gateway startup log shows a related issue:
text
[delivery-recovery] Found 25 pending delivery entries — starting recovery
[delivery-recovery] Recovery time budget exceeded — 25 entries deferred to next restart
[delivery-recovery] Delivery recovery complete: 0 recovered, 0 failed, 0 skipped
This completes in ~8ms, suggesting the time budget check itself is failing instantly. The 25 entries are deferred to next restart but reproduce the same instant timeout on every restart, effectively making them unrecoverable without manual intervention.
Workaround
Switch dmPolicy from allowlist to pairing on all affected accounts. Both Telegram and Matrix begin dispatching messages correctly:
bash
Telegram
for account in atlas panoptes apollo athena hestia theseus; do
openclaw config set channels.telegram.accounts.$account.dmPolicy pairing
done
Matrix
for account in atlas apollo athena hestia theseus chronos midas; do
openclaw config set channels.matrix.accounts.$account.dm '{"policy":"pairing"}'
done
openclaw gateway restart
Setting dmPolicy: "open" also works. The issue is specific to the allowlist enforcement path.
Related Issues
#24670 — WhatsApp/Group policy: fix groupAllowFrom sender filtering when groupPolicy: "allowlist" is set without explicit groups (same bug, fixed for WhatsApp in this release)
#17579 — Slack/Group policy: fix multi-account groupPolicy inheritance (same bug, fixed for Slack in this release)
The fix for Telegram and Matrix should mirror what was done for WhatsApp (#24670) — fall back to top-level channel policy when a per-account allowlist has no explicit allow entries, rather than silently dropping all messages.