hermes - 💡(How to fix) Fix [Bug]: Terminal hang when prompting for confirmation on destructive slash commands (/new, /clear) (windows beta)

Bug Description

This happened with the native windows beta version of hermes and here is the what hermes had to say about it:

Description: When executing a destructive slash command like /new or /clear in the interactive CLI, the application prompts for confirmation ([1] Approve Once, [2] Always Approve). However, the terminal completely hangs at this prompt and stops accepting input, forcing the user to kill the terminal session.

Root Cause Analysis: The hang is caused by a thread collision over stdin between the prompt_toolkit event loop and the built-in input() function.

1. Slash commands are executed on a background daemon thread (process_loop).
2. When /new triggers the confirmation, it calls _prompt_text_input() in cli.py.
3. _prompt_text_input() checks threading.current_thread() is threading.main_thread(). Since it's on a background thread, this evaluates to False.
4. Because it's not on the main thread, it bypasses the safe run_in_terminal(_ask) wrapper and falls back to directly calling the standard Python input() function from the background thread.
5. Meanwhile, the main thread is still running the prompt_toolkit event loop, which is actively consuming stdin.
6. Calling a blocking input() from a secondary thread while prompt_toolkit holds terminal ownership results in a deadlock/hang, particularly on Windows environments.

Workaround:
Users can bypass the hang by disabling the prompt entirely:
hermes config set approvals.destructive_slash_confirm false

Steps to Reproduce

1. Ensure approvals.destructive_slash_confirm is set to true (the default). 2. Open the Hermes interactive CLI in a terminal (Windows git-bash/MSYS). 3. Type /new and press Enter. 4. The confirmation prompt prints to the screen. 5. Attempt to type 1 or 2. The terminal is unresponsive/hung.

Expected Behavior

the terminal is responsive and you can chose your options.

Actual Behavior

it hangs and is unresponsive.

Affected Component

CLI (interactive chat)

Messaging Platform (if gateway-related)

No response

Debug Report

Report     https://paste.rs/4JMDs
  agent.log  https://paste.rs/z6nKA

Operating System

windows 11

Python Version

No response

Hermes Version

No response

Additional Logs / Traceback (optional)

Root Cause Analysis (optional)

No response

Proposed Fix (optional)

No response

Are you willing to submit a PR for this?

• I'd like to fix this myself and submit a PR