Bug Description
[Bug] approvals.mode=manual silently skipped in gateway mode — dangerous commands execute without approval
Environment
|
|
| Version (server) |
v0.9.0 |
| Version (client) |
v0.14.0 |
| Platform |
Feishu (Lark) gateway |
| OS |
Alibaba Cloud Linux 3 (Anolis OS 8) |
| approvals.mode |
manual |
| tirith_enabled |
true |
| auxiliary.approval |
not configured (empty) |
Steps to Reproduce
- Set
approvals.mode: manual in config.yaml, leave auxiliary.approval unconfigured
- Start Hermes in Feishu gateway mode (
hermes gateway run)
- Send a message via Feishu that causes the agent to execute a shell command matching
DANGEROUS_PATTERNS (e.g. triggering hermes gateway restart)
- Observe: the command executes immediately with no approval prompt
Expected Behavior
The agent pauses and presents an approval prompt before executing any command matching DANGEROUS_PATTERNS, regardless of whether it is running in interactive terminal mode or non-interactive gateway mode.
Actual Behavior
No approval prompt appears. The dangerous command executes immediately and silently. In our case this triggered a recursive hermes gateway restart loop, spawning a process chain 6 levels deep before manual intervention, and ultimately re-executed a prior shell command from conversation context:
ssh <host> "curl -fsSL https://tailscale.com/install.sh | sh"
This triggered a worm classification alert from our cloud provider (Alibaba Cloud Security Center) due to the pattern of downloading and executing a remote script across machines.
Root Cause (Suspected)
approvals.mode: manual relies on an interactive TTY to present the approval prompt. In gateway mode (Feishu/Telegram WebSocket), no interactive channel exists — the approval step is silently skipped and execution proceeds as if approved.
Additionally, when auxiliary.approval is unconfigured, the approval subsystem appears to fail open rather than fail closed, defaulting to permissive execution rather than blocking.
Note: this is distinct from #17934 (which covers silent waiting in CLI mode). Here the approval gate does not activate at all in gateway mode.
Additional Issue: DANGEROUS_PATTERNS Bypass via execute_code
Even if a future fix to approvals.mode correctly blocks raw shell strings via regex, the defense can be bypassed when the agent enters a retry loop.
Bypass mechanism: The agent can invoke the execute_code tool to dynamically construct and run a Python or Bash script containing the same dangerous command. Because the raw command string is embedded inside a code execution sandbox, the DANGEROUS_PATTERNS regex layer never inspects it.
Example:
# via execute_code — not inspected by DANGEROUS_PATTERNS
import subprocess
subprocess.run(["hermes", "gateway", "restart"])
This was observed in production. When direct shell execution was blocked, the agent autonomously switched to an alternative execution strategy to accomplish the same outcome.
Impact
- Recursive process chain 6 levels deep before manual intervention
- Cloud provider worm alert triggered (Alibaba Cloud Security Center)
- Prior conversation commands re-executed without user intent
- Reproducible on any non-interactive gateway platform (Feishu, Telegram, Discord, etc.)
- The
execute_code bypass affects all users regardless of DANGEROUS_PATTERNS configuration
Suggested Fixes
- Fail closed in gateway mode: When no interactive TTY is available and
approvals.mode: manual is set, block the command entirely rather than skipping the approval step silently
- Startup warning: Emit a clear warning at gateway startup if
approvals.mode: manual is configured without a working auxiliary.approval model
- Document gateway requirements: Clearly state that gateway mode requires either
mode: tirith or a fully configured auxiliary.approval provider — consider making tirith the default when any gateway platform is active
- Context-aware tool stripping: In non-interactive gateway mode, strip the agent's access to any tool capable of interacting with its own daemon processes — whether via
shell, execute_code, or any other tool. Pattern matching alone is insufficient; the restriction must be enforced at the execution layer
- Principle of least privilege: Gateway mode should launch with a minimal tool set by default — high-risk tools such as
shell and execute_code should require explicit opt-in, not opt-out
- OS-level isolation (documentation): Strongly recommend that production gateway instances are managed by an OS-level supervisor (e.g. systemd) — the agent process should never hold permissions to signal or restart its own parent process
Steps to Reproduce
- Set
approvals.mode: manual in config.yaml, leave auxiliary.approval unconfigured
- Start Hermes in Feishu gateway mode (
hermes gateway run)
- Send a message via Feishu that causes the agent to execute a shell command matching
DANGEROUS_PATTERNS (e.g. triggering hermes gateway restart)
- Observe: the command executes immediately with no approval prompt, triggering a recursive restart loop
Expected Behavior
The agent pauses and presents an approval prompt before executing any command matching DANGEROUS_PATTERNS, regardless of whether it is running in interactive terminal mode or non-interactive gateway mode.
Actual Behavior
No approval prompt appears. The dangerous command executes immediately and silently.
In our case this triggered a recursive hermes gateway restart loop, spawning a process chain 6 levels deep before manual intervention. A prior shell command from conversation context was also re-executed:
ssh <host> "curl -fsSL https://tailscale.com/install.sh | sh"
This triggered a worm classification alert from our cloud provider (Alibaba Cloud Security Center).
Affected Component
Gateway (Telegram/Discord/Slack/WhatsApp)
Messaging Platform (if gateway-related)
No response
Debug Report
◆ Python Environment
✓ Python 3.11.15
✓ Virtual environment active
◆ Configuration Files
✓ ~/.hermes/config.yaml exists
✓ Config version up to date (v17)
◆ Tool Availability
✓ terminal
✓ code_execution
◆ Profiles
✓ invest: gateway running, claude-opus-4-6, no alias
◆ Relevant settings
approvals.mode: manual
tirith_enabled: true
auxiliary.approval: not configured (empty)
Operating System
Alibaba Cloud Linux 3 (Anolis OS 8) — x86_64
Python Version
3.11.15
Hermes Version
v0.9.0
Additional Logs / Traceback (optional)
Root Cause Analysis (optional)
No response
Proposed Fix (optional)
No response
Are you willing to submit a PR for this?
Bug Description
[Bug] approvals.mode=manual silently skipped in gateway mode — dangerous commands execute without approval
Environment
Steps to Reproduce
approvals.mode: manualin config.yaml, leaveauxiliary.approvalunconfiguredhermes gateway run)DANGEROUS_PATTERNS(e.g. triggeringhermes gateway restart)Expected Behavior
The agent pauses and presents an approval prompt before executing any command matching
DANGEROUS_PATTERNS, regardless of whether it is running in interactive terminal mode or non-interactive gateway mode.Actual Behavior
No approval prompt appears. The dangerous command executes immediately and silently. In our case this triggered a recursive
hermes gateway restartloop, spawning a process chain 6 levels deep before manual intervention, and ultimately re-executed a prior shell command from conversation context:This triggered a worm classification alert from our cloud provider (Alibaba Cloud Security Center) due to the pattern of downloading and executing a remote script across machines.
Root Cause (Suspected)
approvals.mode: manualrelies on an interactive TTY to present the approval prompt. In gateway mode (Feishu/Telegram WebSocket), no interactive channel exists — the approval step is silently skipped and execution proceeds as if approved.Additionally, when
auxiliary.approvalis unconfigured, the approval subsystem appears to fail open rather than fail closed, defaulting to permissive execution rather than blocking.Note: this is distinct from #17934 (which covers silent waiting in CLI mode). Here the approval gate does not activate at all in gateway mode.
Additional Issue: DANGEROUS_PATTERNS Bypass via
execute_codeEven if a future fix to
approvals.modecorrectly blocks raw shell strings via regex, the defense can be bypassed when the agent enters a retry loop.Bypass mechanism: The agent can invoke the
execute_codetool to dynamically construct and run a Python or Bash script containing the same dangerous command. Because the raw command string is embedded inside a code execution sandbox, theDANGEROUS_PATTERNSregex layer never inspects it.Example:
This was observed in production. When direct shell execution was blocked, the agent autonomously switched to an alternative execution strategy to accomplish the same outcome.
Impact
execute_codebypass affects all users regardless ofDANGEROUS_PATTERNSconfigurationSuggested Fixes
approvals.mode: manualis set, block the command entirely rather than skipping the approval step silentlyapprovals.mode: manualis configured without a workingauxiliary.approvalmodelmode: tirithor a fully configuredauxiliary.approvalprovider — consider makingtiriththe default when any gateway platform is activeshell,execute_code, or any other tool. Pattern matching alone is insufficient; the restriction must be enforced at the execution layershellandexecute_codeshould require explicit opt-in, not opt-outSteps to Reproduce
approvals.mode: manualin config.yaml, leaveauxiliary.approvalunconfiguredhermes gateway run)DANGEROUS_PATTERNS(e.g. triggeringhermes gateway restart)Expected Behavior
The agent pauses and presents an approval prompt before executing any command matching
DANGEROUS_PATTERNS, regardless of whether it is running in interactive terminal mode or non-interactive gateway mode.Actual Behavior
No approval prompt appears. The dangerous command executes immediately and silently.
In our case this triggered a recursive
hermes gateway restartloop, spawning a process chain 6 levels deep before manual intervention. A prior shell command from conversation context was also re-executed:This triggered a worm classification alert from our cloud provider (Alibaba Cloud Security Center).
Affected Component
Gateway (Telegram/Discord/Slack/WhatsApp)
Messaging Platform (if gateway-related)
No response
Debug Report
Operating System
Alibaba Cloud Linux 3 (Anolis OS 8) — x86_64
Python Version
3.11.15
Hermes Version
v0.9.0
Additional Logs / Traceback (optional)
Root Cause Analysis (optional)
No response
Proposed Fix (optional)
No response
Are you willing to submit a PR for this?