hermes - 💡(How to fix) Fix [Security] No atomic shell-disable mode — toolset updates silently re-expose bash execution to users who opted out

Bug Description

Hermes has no first-class, update-resistant way to fully disable shell/bash access. Users who want a no-shell configuration must manually enumerate and disable each shell-related toolset by name (terminal, process, etc.). This approach is fragile by design: when a new toolset with shell capabilities is added in a future Hermes update, it becomes active automatically — silently re-exposing bash execution to users who explicitly opted out.

There is no safety net, no warning, and no config that says "I never want shell access under any circumstances."

Current Behavior

• Removing shell access requires knowing the exact names of all shell-related toolsets and disabling each one manually.
• No config option exists to express "block all shell execution regardless of what toolsets are installed or updated."
• When Hermes updates and adds a new toolset that includes terminal or subprocess capabilities, it becomes available to the agent without any notification.
• Skills can also re-invoke shell toolsets indirectly.

Expected Behavior

A single, atomic config flag should exist that:

1. Disables all shell/subprocess execution globally, overriding any toolset setting.
2. Is update-resistant — new toolsets added in future versions are blocked by default under this mode.
3. Produces a clear error (not a silent skip) if any skill or tool attempts to invoke a shell under this mode.

Proposed config:

security:
  profile: no_shell   # atomic shell lockdown

This should be equivalent to a deny rule that overrides everything: no subprocess, no os.system, no pty, no terminal toolset — nothing.

Security Impact

• Security-conscious users (production deployments, shared environments, restricted VPS) rely on having no shell access as a hard boundary.
• A Hermes update breaking that boundary silently is a silent security regression with no visible changelog signal.
• This also affects audit compliance: there is currently no way to assert "this Hermes instance cannot execute shell commands" in a way that survives upgrades.

Related Gap

This is compounded by the absence of a toolset allowlist mode (block-by-default). Currently the tool surface is opt-out, not opt-in. A tools.mode: allowlist option would address the same class of problem for the broader tool surface.

Suggested Fix Direction

Add a security.profile: no_shell mode that injects a global pre-execution hook blocking any Python call to subprocess, pty, os.system, or terminal toolset invocations. This hook should run before Tirith, making it impossible to bypass via config or skill instructions.

Environment

• Hermes Agent (latest)
• Any OS
• Reproducible: add any new toolset with shell capabilities while running with terminal toolsets manually disabled