Summary

Telegram/native exec approval appears unreliable for commands targeting a macOS node. In the same Telegram session, a gateway-hosted command approval succeeded, but multiple approvals for the same command targeting a paired macOS node were reported as denied / invoke-failed / did not run, even after the user believed they had approved or sent the suggested /approve ... allow-always command.

This makes remote node administration via Telegram hard to trust: the assistant sees approval failures while the user believes approval was granted.

Environment

• OpenClaw host: macOS on Apple Silicon
• Source channel: Telegram
• Target node: macOS node, MacBook Air M5
• Command type: exec tool with host=node, foreground approval required
• Gateway command approval in the same conversation succeeded
• Node command approval repeatedly failed before execution

What happened

We attempted to install Keka on a remote macOS node using Homebrew:

brew list --cask keka >/dev/null 2>&1 || brew install --cask keka

The exec approval card was generated for the node command. However, after several attempts, the async completion event reported that the command did not run because approval was denied / invoke-failed. No command output was produced.

Meanwhile, a similar approval flow for a gateway-hosted command in the same Telegram conversation completed successfully.

Expected behavior

One of these should happen reliably:

1. Clicking/sending the approval in Telegram should approve the pending node exec command and let it run; or
2. If Telegram cannot route /approve for node approvals, the UI should clearly show why and provide a working approval path; or
3. allow-always should persist and apply consistently for subsequent matching node commands.

Actual behavior

• Gateway-hosted approval succeeded.
• Node-hosted approval repeatedly ended with “command did not run” / denied / invoke-failed.
• The user believed approval had been granted, but the assistant received only failure completion events.
• Re-sending new approval cards did not resolve the node command approval path.

Why this matters

This is confusing for users and agents:

• The user sees/uses an approval flow but the command never runs.
• The assistant cannot tell whether the issue is Telegram command routing, approval expiry, node/gateway approval propagation, or allowlist persistence.
• It creates a bad loop where the assistant keeps asking for approval and the user keeps approving, but the node command remains blocked.

Related issues found during search

Possibly related but not identical:

• #2402 — exec approval flow fire-and-forget / orphaned approvals
• #44749 — concurrent approvals delayed completion / user commands blocked
• #67440 — allow-always entries race / allowlist persistence
• #68634 — Telegram native approvals / gateway noise
• #30924 — allowFrom ignored / approvals still required

Suggested diagnostics / fixes

• Confirm whether Telegram /approve commands are routed globally or only to gateway-local approvals.
• Add explicit logging for approval target host/node and approval routing result.
• When an approval fails because it was not received, expired, denied, or routed to the wrong session/node, surface that reason distinctly.
• Add a command or UI to list active pending approvals with target host/node and expiry.
• Ensure allow-always persistence is atomic and applies consistently across gateway vs node exec targets.