hermes - 💡(How to fix) Fix feat: /yolo <duration> and /yolo until <time> — bounded auto-expiry for yolo mode

Problem

/yolo is a binary on/off toggle for the session — there is no way to bound it to a duration or expiry time. Today users have two unappealing options:

1. Toggle /yolo on, do the work, remember to toggle it back off — easy to forget, especially mid-conversation.
2. Leave the session running with yolo on indefinitely — fine for short tasks, but routine context-switches (lunch, a new ticket, end of day) leave a long-lived session in unconfirmed-execute mode.

There is no built-in "yolo for the next 30 minutes" or "yolo until 6pm". The only auto-revert today is exiting the session.

Proposed feature

Extend the existing slash command with optional duration / until-time args. This is a small additive change on top of the existing yolo plumbing — it does not replace any of the broader work in #21849 (per-tool permission rules) and is intended to ship independently.

/yolo                         # current behavior — toggle on/off, no expiry
/yolo 30m                     # on for 30 minutes, then auto-off
/yolo 2h                      # on for 2 hours
/yolo until 18:00             # on until 6pm local time today
/yolo until 2026-05-13T18:00  # on until specific ISO timestamp
/yolo off                     # explicit off (cancels any pending expiry)
/yolo status                  # show current state + remaining time if timed

Equivalent CLI flag: --yolo 30m, --yolo-until 18:00.

Behavior

• When timed yolo is active, the status line / footer shows remaining time (e.g. yolo on (28m left)).
• Expiry fires a single audit log entry and a system message in the transcript: yolo expired — approvals re-enabled.
• If a dangerous command is mid-flight when expiry hits, let it complete — expiry only affects new approval checks. (Killing in-flight tool calls would be surprising and could leave half-done work.)
• Hardline patterns remain blocked — unchanged.
• The user-facing safety message is unchanged: yolo means user trusts the agent with their files/services for a window; hardline still applies.

Implementation sketch

The existing yolo state is a plain bool in session state. Replace with a small struct:

@dataclass
class YoloState:
    enabled: bool
    expires_at: Optional[float] = None  # unix epoch; None = no expiry

    def is_active(self) -> bool:
        if not self.enabled:
            return False
        if self.expires_at is not None and time.time() >= self.expires_at:
            return False
        return True

Touch points:

• tools/approval.py — replace bool checks with state.is_active().
• hermes_cli/commands.py — extend args_hint on the existing CommandDef("yolo", ...).
• cli.py — extend the /yolo handler to parse the arg (30m, 2h, until HH:MM, until <iso>).
• TUI useInputHandlers.ts — Shift+Tab keeps current "indefinite toggle" behavior; expiry surfaces via the existing gateway.ready / status updates.
• gateway/run.py — same arg parsing; one extra field in the status payload so platform UIs can render the remaining time.

No background timer thread is needed — is_active() is checked lazily on each approval call, so expiry takes effect on the next check after the timestamp has passed.

Bonus (optional)

A config default: approvals.yolo_default_duration: 30m — when set, bare /yolo (no arg) uses this duration instead of indefinite. Users who want the safety net by default opt in once and never think about it again.

Why this and not #21849?

#21849 proposes a full per-tool permission gating system — that's the right long-term architecture and this request is not trying to short-circuit it. But:

• #21849 is a substantial design + implementation effort.
• The duration knob here is a small additive change that lives entirely inside the existing yolo path.
• It's strictly additive — when #21849 lands, the duration concept maps cleanly onto its mode-fallback layer (a "permissive mode with expiry").

Environment

• Hermes Agent (current main)
• Linux, GCP VM
• Affects CLI, TUI, and gateway sessions

cc related: #21849, #3765, #4067