hermes - 💡(How to fix) Fix [Bug]: API Server/WebUI path cannot surface dangerous command approval prompts [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
NousResearch/hermes-agent#15802Fetched 2026-04-26 05:24:57
View on GitHub
Comments
0
Participants
1
Timeline
4
Reactions
0
Author
Participants
Timeline (top)
labeled ×4

Root Cause

From code inspection:

  • tools/approval.py already contains the approval queue, register_gateway_notify(), and resolve_gateway_approval().
  • Telegram/Feishu/etc. implement send_exec_approval().
  • gateway/platforms/api_server.py creates and runs AIAgent directly but does not appear to register an approval notification callback for API-server sessions.
  • API Server does not expose approval.required SSE events or an approval resolution endpoint.

This seems related in shape to #10760, where API Server/WebUI misses gateway-session behavior that works on native gateway platforms.

RAW_BUFFERClick to expand / collapse

Bug Description

Dangerous command approvals work on native gateway platforms such as Telegram, Discord, Slack, and Feishu because those adapters implement interactive approval prompts.

However, when the same workflow runs through the API Server path, such as hermes-web-ui / local dashboard / /v1/runs, dangerous command approval is not surfaced to the user. The WebUI may show the assistant saying it is waiting for approval, but no approval card/button appears, and the command eventually times out or is denied.

Steps to Reproduce

  1. Run Hermes Agent with API Server enabled and connect through hermes-web-ui.
  2. Ask the agent to run a command that triggers dangerous-command approval, e.g. a command matching the hermes update approval pattern.
  3. Observe the WebUI chat.

Expected Behavior

API Server should emit a structured approval event over /v1/runs/{run_id}/events, for example:

{ "event": "approval.required", "run_id": "run_xxx", "approval_id": "appr_xxx", "command": "hermes update --check 2>&1 || true", "description": "hermes update (restarts gateway, kills running agents)", "choices": ["once", "session", "always", "deny"] }

It should also expose an authenticated resolve endpoint, for example:

POST /v1/approvals/{approval_id}/resolve

{ "choice": "once" }

This endpoint should unblock the pending approval via the same underlying mechanism used by gateway buttons or /approve.

Actual Behavior

No approval event/card is exposed for API Server/WebUI sessions. API Server clients cannot approve dangerous commands even though approvals work on native messaging platforms.

Root Cause Analysis

From code inspection:

  • tools/approval.py already contains the approval queue, register_gateway_notify(), and resolve_gateway_approval().
  • Telegram/Feishu/etc. implement send_exec_approval().
  • gateway/platforms/api_server.py creates and runs AIAgent directly but does not appear to register an approval notification callback for API-server sessions.
  • API Server does not expose approval.required SSE events or an approval resolution endpoint.

This seems related in shape to #10760, where API Server/WebUI misses gateway-session behavior that works on native gateway platforms.

Proposed Fix

Add first-class approval support to the API Server platform:

  1. Bind the correct session key in the /v1/runs execution path.
  2. Register an approval notification callback.
  3. Push approval.required events into the run SSE queue.
  4. Track approval_id -> session_key.
  5. Add POST /v1/approvals/{approval_id}/resolve.
  6. Call resolve_gateway_approval(session_key, choice).
  7. Optionally emit approval.resolved so WebUI can update the card state.

Affected Component

gateway/platforms/api_server.py

extent analysis

TL;DR

To fix the issue, add first-class approval support to the API Server platform by registering an approval notification callback and exposing approval events and resolution endpoints.

Guidance

  • Review the gateway/platforms/api_server.py component to ensure it registers an approval notification callback for API-server sessions.
  • Verify that the API Server emits approval.required events over the /v1/runs/{run_id}/events endpoint.
  • Implement the POST /v1/approvals/{approval_id}/resolve endpoint to unblock pending approvals.
  • Consider emitting approval.resolved events to update the WebUI card state.

Example

# gateway/platforms/api_server.py
def register_approval_callback(session_key):
    # Register approval notification callback for API-server sessions
    pass

def resolve_approval(approval_id, choice):
    # Call resolve_gateway_approval with the correct session key
    session_key = get_session_key(approval_id)
    resolve_gateway_approval(session_key, choice)

Notes

The proposed fix involves modifying the gateway/platforms/api_server.py component to add first-class approval support. This may require additional changes to other components or dependencies.

Recommendation

Apply the proposed fix to add first-class approval support to the API Server platform, as it addresses the root cause of the issue and provides a comprehensive solution.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

hermes - 💡(How to fix) Fix [Bug]: API Server/WebUI path cannot surface dangerous command approval prompts [1 participants]