Summary

On Feishu, approval-related flows can degrade into manual /approve ... text without a clear enough explanation of why interactive buttons are unavailable in that moment, or what the user should do next.

This creates a confusing experience:

• OpenClaw indicates approval is needed
• the user may expect an in-channel interactive approval flow
• but instead receives raw /approve ... text
• and the fallback path is not always explained clearly enough

Why this matters

This is not simply a cosmetic Feishu issue.
It affects whether approvals feel reliable and discoverable on real chat surfaces.

If a channel/surface cannot support the richer approval UX in a given moment, the degradation should be explicit and clean.

Real scenario

In a Feishu-connected OpenClaw setup with channels.feishu.capabilities = ["inlineButtons"], approval-related flows still sometimes fell back to plain /approve ... text.

This makes the situation ambiguous for the user:

• Is Feishu interactive approval unsupported for this flow?
• Are interactive buttons unavailable on this surface/context?
• Did the approval message degrade because of channel constraints?
• Should the user complete approval in Feishu, in web UI, or in terminal?

The current UX does not make that distinction clear enough.

Expected behavior

If interactive approval buttons are unavailable, unsupported, or degraded in the current surface/context, OpenClaw should say so explicitly and give a cleaner fallback instruction path.

For example, approval messages could make clear:

• interactive buttons unavailable on this surface/context
• manual approval required
• exact fallback command
• whether approval can still be completed in-channel, or must be completed in terminal/web UI

Actual behavior

The user can end up with raw /approve ... text and too little guidance about why the UX degraded or which surface is the right one to finish the action.

Suggested improvement directions

1. Make approval messages more explicit about current surface/channel capability.
2. Normalize fallback copy when interactive approval is unavailable.
3. Distinguish clearly between:
   • channel supports inline buttons in general
   • this specific approval flow supports interactive completion here
4. Document approval UX differences across channels/surfaces, especially Feishu.

Related

This is related to, but not the same as, #58298 (message tool support for Feishu interactive cards).

That issue is about agent-authored interactive cards.
This issue is about built-in approval UX fallback clarity when approval does not remain interactive for the user.

Environment

• OpenClaw version: 2026.4.15
• Channel: Feishu
• Connection mode: websocket
• Feishu capabilities included inlineButtons