openclaw - 💡(How to fix) Fix [Bug]: Telegram/mobile approvals can resolve as "unknown or expired approval id" after pending approval creation [3 comments, 4 participants]

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Telegram/mobile approval flows sometimes fail with unknown or expired approval id even after approval creation was observed in logs.

Steps to reproduce

1. Trigger a command that requires approval from a Telegram/OpenClaw chat.
2. Wait for the approval prompt/card to appear.
3. Attempt to approve via the client flow being tested.
4. Observe cases where logs show approval creation/registration, but resolution later returns unknown or expired approval id.

Expected behavior

A created and registered approval should remain resolvable until it is explicitly approved, denied, or expires according to its configured TTL.

Actual behavior

Observed logs showed approval lifecycle entries followed by failures such as exec.approval.resolve unknown or expired approval id and plugin.approval.resolve unknown or expired approval id. In other cases, a request was created, registered, and then explicitly resolved with decision:"deny" and resolvedBy:"X’s MacBook Pro".

OpenClaw version

2026.3.31

Operating system

Linux 6.8.0-106-generic (x64)

Install method

Docker (on VPS)

Model

openai/gpt-5.4

Provider / routing chain

Telegram → OpenClaw Gateway → tool approval flow (exec / plugin approval resolution)

Additional provider/model setup details

• Direct-message Telegram chat on VPS deployment • Gateway health and manifest endpoints were later verified healthy (returned 200) • Manifest DB corruption was separately observed and fixed during investigation; this was associated with repeated gateway restarts • Telegram configWrites had been enabled earlier and was later changed to reduce restart churn • Approval traces captured both exec.approval.resolve and plugin.approval.resolve failures with unknown or expired approval id

Logs, screenshots, and evidence

Observed evidence from investigation and traces:

• Approval failures:
  • exec.approval.resolve ... unknown or expired approval id
  • plugin.approval.resolve ... unknown or expired approval id
• Observed lifecycle for a separate request:
  • approval.created
  • approval.registered
  • approval.resolved with decision:"deny" and resolvedBy:"X’s MacBook Pro"
• Manifest instability observed during the same investigation:
  • QueryFailedError: database disk image is malformed
• Verification after manifest DB reset:
  • IP1 → 200
  • IP2 → 200
  • recreated manifest.db passed PRAGMA integrity_check = ok
  • openclaw doctor --non-interactive completed successfully

Impact and severity

Affected users/systems/channels: Telegram direct-chat approval flow on this OpenClaw VPS deployment Severity: Blocks workflow when approval-gated commands cannot be executed Frequency: Intermittent Consequence: Commands requiring approval fail to run; investigation time increases because some requests show created/registered approvals while later resolution fails with unknown or expired approval id

Additional information

• This report is grounded in observed logs from the investigated deployment. • Separate deployment instability was also observed during investigation due to manifest DB corruption and resulting restarts. • At least one later approval trace showed an explicit deny decision rather than an expiry/missing-state failure, so not every failed command belonged to the same failure mode. • Last known good: NOT_ENOUGH_INFO • First known bad: NOT_ENOUGH_INFO