Summary

• Schedule prompt_toolkit.application.run_in_terminal(...) on the active prompt_toolkit app loop before calling it from background slash-command threads.
• Fix destructive slash command confirmation prompts such as /new, /reset, /clear, and /undo when prompt_toolkit returns an awaitable.
• Apply the same awaitable handling to related terminal-bridged call sites for curses picker, background _cprint, and Ctrl+Z suspend.
• Add a regression test covering _prompt_text_input from a process-loop-like background thread while run_in_terminal executes on the app-loop thread.

Related issues / PRs

• Related to [Bug]: /clear, /new, /reset, /undo confirmation prompt cannot be answered — keystrokes leak into chat composer #22958: destructive slash-command confirmation prompts in TUI mode.
• Addresses the run_in_terminal(...) awaitable root cause of fix(cli): RuntimeWarning in /new, /clear, /undo, /reload-mcp — coroutine was never awaited #22970 and duplicate report bug: /reload-mcp triggers RuntimeWarning from unawaited run_in_terminal coroutine #23009: RuntimeWarning: coroutine 'run_in_terminal.<locals>.run' was never awaited.
• Overlaps with fix(cli): use prompt_toolkit.prompt() for TUI confirmation prompts (Fixes #22958) #22989, which changes the prompt implementation itself (input() -> prompt_toolkit prompt). This PR focuses on safely scheduling/awaiting run_in_terminal(...) from background-thread call sites and includes a regression test for that path.

Why

/new and other destructive slash commands run their confirmation flow from the CLI process_loop background thread while prompt_toolkit owns the terminal on its application event loop. In prompt_toolkit 3.x, run_in_terminal(...) returns/schedules an awaitable and must be called from the app loop. Calling it directly from the background thread can drop the prompt and emit:

RuntimeWarning: coroutine 'run_in_terminal.<locals>.run' was never awaited

How to test

Reproduction before this fix:

1. Start interactive Hermes CLI.
2. Enter /new.
3. Observe the destructive-command confirmation fail with the unawaited coroutine warning.

After this fix:

1. Start interactive Hermes CLI.
2. Enter /new.
3. The confirmation prompt appears.
4. Enter 3 to cancel.
5. Hermes reports /new cancelled without the coroutine warning.

Platforms tested

• macOS
• Python 3.11
• prompt_toolkit 3.0.52

Test Plan

Verified in a fresh clone following the CONTRIBUTING setup instructions on commit 3bc8df818.

Passed:

• venv/bin/python -m py_compile cli.py tests/cli/test_cprint_bg_thread.py
• venv/bin/python scripts/check-windows-footguns.py cli.py tests/cli/test_cprint_bg_thread.py
• scripts/run_tests.sh tests/cli/test_cprint_bg_thread.py tests/hermes_cli/test_destructive_slash_confirm_gate.py
  • 17 passed

Manual verification:

• Started Hermes with an isolated temporary home directory, ran /new, selected 3 to cancel, and verified the confirmation prompt worked without the unawaited coroutine warning.

Full-suite note:

• Attempted scripts/run_tests.sh tests in a fresh clone. It did not complete green (16333 passed, 75 skipped, 33 failed, 5057 errors), with broad unrelated-looking failures across plugin/skill/TUI/website tests. A representative reported failing test passed when rerun in isolation, so I did not treat this as related to this CLI fix.
• scripts/run_tests.sh with no args currently fails locally with ARGS[@]: unbound variable; scripts/run_tests.sh tests was used for the full-suite attempt.