hermes - 💡(How to fix) Fix /steer leaves submitted prompt in TUI input buffer, allows accidental re-submit

Bug Summary

Hermes Agent CLI TUI: when a user submits a /steer <prompt> while Hermes is working on a previous turn, the submitted prompt text reappears in the input field as if it had not been submitted. If the user hits Enter (or the auto-resume / next-turn handoff fires), the same prompt is re-sent and re-processed. User must manually clear the input field to prevent the unintended re-submission.

This is a real workflow hazard — /steer is specifically designed for mid-turn injection, and double-firing the injected prompt is the opposite of its purpose.

Reproduction

• Substrate: Hermes Agent CLI (TUI mode, not gateway), macOS 26.5, prompt_toolkit
• Profile: any (observed on the default profile while running anthropic/claude-opus-4.7 via Nous Portal)
• Trigger: type /steer <prompt> while Hermes is working on a previous turn
• display.busy_input_mode: interrupt (default — confirmed in ~/.hermes/config.yaml; never changed by user)
• Observed: the typed prompt text re-appears in the input buffer after submission. The visible message-history echo / re-send pathway has not been verified — user describes the visible state as "the prompt repeats, shows up again and has to be manually deleted in the TUI lest it be repeated"

Expected Behavior

After /steer <prompt> is submitted, the input field should be cleared (same as a normal prompt submission). The steered prompt should be injected after the next tool call (per the slash command docstring: "Inject a message after the next tool call without interrupting") and the input buffer should NOT contain a stale copy that could be re-submitted.

Hypothesis (likely areas to investigate)

1. /steer handler in cli.py — the input-clearing logic may not run for /steer-prefixed input when display.busy_input_mode=interrupt. The interrupt path may bypass the post-submit buffer clear that normal prompts get.
2. prompt_toolkit buffer state interaction with display.busy_input_mode=interrupt — /queue and /steer both target the busy-state path; the buffer-clear callback may be wired only for queue not steer (or only for interrupt not the other two modes).
3. Race condition between turn-handoff and buffer reset — if the steer text is consumed asynchronously (queued for the next tool-call boundary), the synchronous buffer clear that normally fires on Enter may not be triggered because the input was special-cased as a slash command.

Repo references to start from:

• hermes_cli/commands.py — /steer CommandDef registration
• cli.py — process_command() slash command dispatch + _bind_prompt_submit_keys
• agent/ — where steer-injected messages are queued
• display.busy_input_mode config schema — cli.py / hermes_cli/config.py

Impact

• Workflow hazard: double-firing the same steer message can produce wasted token spend, unintended state changes (if the steer was an action prompt), and confusion in the conversation log.
• Trust signal: the TUI's input-state contract is "what's in the box is what hasn't been sent." Violating that contract is a usability and trust regression.
• Frequency: appears consistent — user reports this is a repeatable bug, not a one-off race.

References

• Hermes Agent docs: https://hermes-agent.nousresearch.com/docs/reference/slash-commands
• Slash command /steer: "Inject a message after the next tool call without interrupting"
• Config: display.busy_input_mode (values: queue, steer, interrupt; default: interrupt)