Summary

Fixes #33925.

The CLI's in-chat /yolo toggled os.environ["HERMES_YOLO_MODE"] but never bypassed approvals — that env var is captured once at module-import time into tools/approval.py:_YOLO_MODE_FROZEN (a deliberate security floor that stops prompt-injected skills from flipping the bypass mid-run), so any post-import flip is a silent no-op. The CLI handler also didn't call enable_session_yolo() the way the gateway and TUI handlers do, so the per-session bypass path couldn't fire either.

Net effect: the status bar showed ⚠ YOLO while every dangerous command still hit the approval prompt or got denied. Only hermes --yolo (set before tool imports), HERMES_YOLO_MODE=1 hermes ..., and hermes config set approvals.mode off actually bypassed.

Changes

• cli.py:_toggle_yolo() — now calls enable_session_yolo(self.session_id) / disable_session_yolo(self.session_id) instead of mutating the env var. Matches gateway/run.py:_handle_yolo_command and tui_gateway/server.py key=="yolo".
• cli.py:run_agent() (inside process_input) — binds set_current_session_key(self.session_id) around run_conversation() so is_current_session_yolo_enabled() resolves against the same key the toggle writes under. Resets in finally so reused threads don't see stale identity. Mirrors tui_gateway/server.py:3496-3812 and gateway/platforms/api_server.py:3658-3672.
• cli.py:_is_session_yolo_active() — new helper that replaces the two bool(os.getenv("HERMES_YOLO_MODE")) reads in the status-bar builders (cli.py:3750, cli.py:3811). Reads the live session-yolo state and still honors _YOLO_MODE_FROZEN so hermes --yolo continues to light up the badge.
• tests/cli/test_cli_yolo_toggle.py — 8 new regression tests covering: ON/OFF toggle, no env-var mutation, missing-session_id fallback to "default", two-session isolation, status-bar helper, _YOLO_MODE_FROZEN interaction, and an end-to-end check that check_all_command_guards actually auto-approves after the toggle.

The _YOLO_MODE_FROZEN security freeze itself is preserved — env-var-based opt-in still only works when set before process start, which is the documented contract for --yolo / HERMES_YOLO_MODE.

Test Plan

$ python -m pytest tests/cli/test_cli_yolo_toggle.py -v
============================== 8 passed in 0.19s ==============================

$ python -m pytest tests/tools/test_yolo_mode.py tests/tools/test_approval.py \
    tests/gateway/test_yolo_command.py tests/tools/test_cron_approval_mode.py \
    tests/cli/test_cli_init.py -q
............................................................................... 232 passed

$ python -m pytest tests/cli/test_cli_init.py tests/gateway/test_yolo_command.py -q
42 passed in 0.92s

Manual repro verified before/after on origin/main:

• Before: hermes → /yolo → status bar shows ⚠ YOLO → rm -rf /tmp/foo → still prompts.
• After: hermes → /yolo → status bar shows ⚠ YOLO → rm -rf /tmp/foo → auto-approved.

Related

• Dashboard UI: approvals.mode missing 'smart' option, shows stale option names #31925 / fix(dashboard): correct approvals.mode select options #31933 — dashboard UI's approvals.mode dropdown shows stale ["ask", "yolo", "deny"] instead of the values the normalizer accepts (["manual", "smart", "off"]). Same family of bug (UI surface that doesn't actually toggle approvals). Out of scope here, but the user who reported CLI /yolo (in-chat) does not bypass dangerous command approvals — env var freeze + missing enable_session_yolo call #33925 also hit that path.
• CLI status bar treats HERMES_YOLO_MODE=false as YOLO enabled #33605 — closed, status bar treated HERMES_YOLO_MODE=false as YOLO on. Cleaned up the same status-bar reads we touch here.
• fix(tools): approval revocation enforcement, YOLO mode bypass, and MCP/plugin audit logs #32705 — fix for YOLO bypass in computer_use; different scope, doesn't touch the CLI /yolo path.