hermes - 💡(How to fix) Fix [Bug]: [Security] approvals.mode=manual silently bypassed in gateway mode — dangerous commands execute without approval, including via execute_code sandbox evasion [1 pull requests]

Bug Description

[Bug] approvals.mode=manual silently skipped in gateway mode — dangerous commands execute without approval

Environment

Steps to Reproduce

1. Set approvals.mode: manual in config.yaml, leave auxiliary.approval unconfigured
2. Start Hermes in Feishu gateway mode (hermes gateway run)
3. Send a message via Feishu that causes the agent to execute a shell command matching DANGEROUS_PATTERNS (e.g. triggering hermes gateway restart)
4. 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

1. 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
2. Startup warning: Emit a clear warning at gateway startup if approvals.mode: manual is configured without a working auxiliary.approval model
3. 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
4. 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
5. 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
6. 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

1. Set approvals.mode: manual in config.yaml, leave auxiliary.approval unconfigured
2. Start Hermes in Feishu gateway mode (hermes gateway run)
3. Send a message via Feishu that causes the agent to execute a shell command matching DANGEROUS_PATTERNS (e.g. triggering hermes gateway restart)
4. 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?

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