Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

In OpenClaw 2026.3.28, Telegram DM exec approvals are delivered to the configured approver, but after approving the request in Telegram, the gateway fails to consume the approval correctly and logs:

• exec.approval.resolve ... errorCode=INVALID_REQUEST errorMessage=unknown or expired approval id
• plugin.approval.resolve ... errorCode=INVALID_REQUEST errorMessage=unknown or expired approval id

This reproduces on a minimal harmless command and still occurs after changing Telegram from dmPolicy: "pairing" to dmPolicy: "allowlist" with explicit allowFrom.

This appears related to the recent approval-ID / approval-consumption bug family already reported in #55853 and #57037, but this report is specifically for Telegram DM approval flow, not webchat.

Steps to reproduce

1. Configure Telegram exec approvals for a single approver in DM.
2. Trigger a command that requires approval.
3. Receive the approval prompt in Telegram DM.
4. Approve it promptly in Telegram.
5. Observe gateway logs.

Expected behavior

Approving the request in Telegram should consume the pending approval and allow the command to resume/complete normally.

Actual behavior

The command approval flow does not resolve cleanly. Gateway logs show:

2026-03-29T15:54:59.970Z info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✗ exec.approval.resolve 0ms errorCode=INVALID_REQUEST errorMessage=unknown or expired approval id conn=15ed75de…35a8 id=f5a5d369…b96f
2026-03-29T15:54:59.992Z info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✗ plugin.approval.resolve 0ms errorCode=INVALID_REQUEST errorMessage=unknown or expired approval id conn=aac7a7b2…c057 id=5a5bbe9c…fde5

OpenClaw version

2026.3.28

Operating system

macOS 26.4.0

Install method

npm / Homebrew-hosted global package path under /opt/homebrew/lib/node_modules/openclaw

Model

gpt-5.4

Provider / routing chain

openai-codex

Additional provider/model setup details

Surface initiating the request: Slack thread
Approval surface: Telegram DM
Telegram bot health: OK

Logs, screenshots, and evidence

Minimal repro command used:

python3 - <<'PY'
print('approval test from workspace')
PY

Observed gateway logs:

2026-03-29T15:54:59.970Z info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✗ exec.approval.resolve 0ms errorCode=INVALID_REQUEST errorMessage=unknown or expired approval id conn=15ed75de…35a8 id=f5a5d369…b96f
2026-03-29T15:54:59.992Z info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✗ plugin.approval.resolve 0ms errorCode=INVALID_REQUEST errorMessage=unknown or expired approval id conn=aac7a7b2…c057 id=5a5bbe9c…fde5

Additional possibly related runtime signal seen during the same session:

[ws-stream] WebSocket connect failed for session=...; falling back to HTTP. error=Error: Unexpected server response: 500

Notes:
- Telegram approval prompt was delivered successfully to the configured approver.
- Telegram channel health reported OK.
- The failure occurs when OpenClaw tries to resolve/consume the approval, not when sending the approval request.
- This appears related to the same approval-ID / stale approval family discussed in #55853 and #57037, but reproduced here via Telegram DM approvals.

Impact and severity

Telegram is a documented approval-capable surface, so this breaks a core remote approval workflow even when the bot is healthy and properly configured.

Additional information

• Not caused by Telegram being disabled or unhealthy: Telegram status is OK.
• Not caused by missing approver configuration: execApprovals.approvers is set correctly.
• Not caused by DM access policy alone: reproduces after switching from dmPolicy: "pairing" to dmPolicy: "allowlist".
• Not caused by command complexity: reproduces with a minimal harmless heredoc Python print.

Additional possibly related signal observed during the same testing session:
[ws-stream] WebSocket connect failed for session=...; falling back to HTTP. error=Error: Unexpected server response: 500

This may indicate session/approval state drift during async approval handoff.

Likely related issues:

• Webchat control UI Approve button does not consume pending exec approval; repeated exec gets a new approval id #55853
• [Bug]: webchat exec approval handoff fails after Allow once; retry generates a new approval ID instead of resuming execution #57037