hermes - 💡(How to fix) Fix config docs claim TIRITH_ENABLED env var works but cli.py only reads from security_cfg dict (silently ignored)

Summary

hermes_cli/config.py line 4441 documents:

tirith pre-exec scanning is enabled by default when the tirith binary
is available. Configure via security.tirith_* keys or env vars
(TIRITH_ENABLED, TIRITH_BIN, TIRITH_TIMEOUT, TIRITH_FAIL_OPEN).

But the actual code path at cli.py:12044 reads:

tirith_enabled = security_cfg.get("tirith_enabled", True)

…only from the security config dict. The env var TIRITH_ENABLED is never consulted in the enabled/disabled branch. Setting TIRITH_ENABLED=false in ~/.hermes/.env does not disable tirith.

Reproduction

1. echo "TIRITH_ENABLED=false" >> ~/.hermes/.env
2. Restart Hermes gateway
3. Verify env var is loaded by Hermes (e.g. log output of agent.log shows Loaded environment variables from /home/rkt2/.hermes/.env)
4. Issue an agent command that would trigger tirith (e.g. curl URL | python3)
5. Bug: tirith still scans and rejects. Env var ignored.

Workaround: must set security.tirith_enabled: false in ~/.hermes/config.yaml instead.

Expected behavior

Either:

• (a) Make TIRITH_ENABLED (and TIRITH_BIN, TIRITH_TIMEOUT, TIRITH_FAIL_OPEN) actually work as documented — read env in the config-resolution path.
• (b) Remove the env-var advertisement from the docstring at config.py:4441 and from cli-config.yaml.example line 4441.

(a) is preferred — operators expect environment variables to override config values, and the rest of Hermes' config system supports this pattern.

Impact

Diagnostic time loss only — no security impact. But operators waste hours assuming the documented config knob works when it doesn't. Encountered during paperclipai/paperclip integration diagnostic 2026-05-20.

Severity

Low (documentation/UX). Filing because the cost-of-confusion is real and the fix is trivial either way.

Submitted with assistance from Claude Opus 4.7 via Claude Code.