Problem or Use Case

Problem

In the Telegram gateway, command approval prompts initially include the command and approval context.

However, after a button is clicked, the message is edited to a generic status like:

• ✅ Approved once by <user>
• ✅ Approved for session by <user>
• ✅ Approved permanently by <user>
• ❌ Denied by <user>

At that point, the command itself is no longer visible in the chat.

Why this is a problem

This makes the in-chat audit trail weak:

• users cannot easily see what was approved or denied
• long-running sessions with multiple approvals become ambiguous
• verifying a misclick requires checking logs instead of reading the session

Proposed Solution

Expected behavior

After approval or denial, the edited Telegram message should still include a compact command preview and, ideally, the approval description.

For example:

• ✅ Approved for session by <user>
• Command: systemctl --user restart hermes-gateway
• Reason: dangerous command

A shorter equivalent would also be fine, as long as the approved/denied action remains visible in the session.

Implementation idea

Store richer approval state per approval ID, not just the session key. For example:

• session_key
• command
• description

Then use that data when editing the resolved approval message.

Scope

This issue is specifically about Telegram command approval button flows.
Scope: How big is this change?

This should be a small, localized change.

Likely touch points

1. gateway/platforms/telegram.py
   This is the main place to change.

The main change would be:

• store richer approval state per approval ID, not just the session key
• include fields such as:
  • session_key
  • command
  • description
• when the callback is resolved, use that stored data to edit the Telegram message with:
  • approval result
  • actor
  • compact command preview
  • optional description / risk label

In other words, this is mostly a message-state and rendering change in the Telegram gateway.

2. gateway/run.py (optional / follow-up)
   This may also be worth updating if text-based /approve and /deny flows currently resolve with similarly generic responses.

That part would be optional if the issue is scoped only to:

• Telegram inline approval buttons

But if maintainers want consistency across approval flows, gateway/run.py is the obvious follow-up place.

Alternatives Considered

No response

Feature Type

Gateway / messaging improvement

Scope

Small (single file, < 50 lines)

Contribution

• I'd like to implement this myself and submit a PR

Debug Report (optional)