run_in_terminal() coroutines not awaited — silent message loss (output) + broken input on WSL

[yonghuatrc]

Summary

run_in_terminal() from prompt_toolkit is an async function that always returns a coroutine. Multiple call sites in cli.py invoke it without await and without a fallback, causing two distinct bugs that share the same root cause.

---

Bug A — Silent output loss in _cprint() (line 1515)

File: cli.py, function _cprint(), inside closure _schedule()

def _schedule():
    try:
        run_in_terminal(lambda: _pt_print(_PT_ANSI(text)))  # NOT awaited
    except Exception:
        try:
            _pt_print(_PT_ANSI(text))
        except Exception:
            pass

try:
    loop.call_soon_threadsafe(_schedule)
except Exception:
    ...

What happens: run_in_terminal() returns a coroutine that is passed to call_soon_threadsafe. The callback is scheduled, but the coroutine object itself is never awaited — it gets garbage collected by Python, triggering RuntimeWarning: coroutine 'run_in_terminal.<locals>.run' was never awaited.

Impact: When _cprint fires from a background thread (e.g., process_loop, voice auto-restart thread, self-improvement summaries), the printed text is silently dropped. The warning message "process_loop unhandled error (msg may be lost)" at line 12338 is the symptom of this.

Trigger: Background thread calls _cprint while the prompt_toolkit app loop is running on a different thread — specifically when get_running_loop() succeeds and differs from app.loop.

---

Bug B — Broken input prompt on WSL in _prompt_text_input() (line 5876)

File: cli.py, function _prompt_text_input()

def _prompt_text_input(self, prompt_text: str) -> str | None:
    ...
    if self._app:
        from prompt_toolkit.application import run_in_terminal
        ...
        try:
            run_in_terminal(_ask)  # NOT awaited, no fallback on WSL
        finally:
            ...

What happens: On WSL terminals (Warp, PowerShell, etc.), the run_in_terminal() coroutine is scheduled but the event loop fails silently to execute it. No exception propagates up, no fallback runs, result[0] stays None.

Impact: The input prompt never displays. User keystrokes go to the agent buffer instead of the confirmation prompt — making it appear the agent is consuming their input.

---

Root Cause

prompt_toolkit.application.run_in_terminal() (v3.0.52+):

def run_in_terminal(func: Callable[[], _T], ...) -> Awaitable[_T]:
    async def run() -> _T:
        async with in_terminal(...):
            return func()
    return ensure_future(run())  # always returns a coroutine (Future)

Every call site must either await the returned coroutine or wrap in try/except with a direct fallback.

---

Fix Summary

• Bug A (_cprint): Await the coroutine via asyncio.ensure_future() inside the callback, or use loop.call_soon_threadsafe with asyncio.create_task pattern.
• Bug B (_prompt_text_input): Add except Exception: _ask() after run_in_terminal(_ask) to provide the direct fallback when run_in_terminal fails on WSL.

---

Environment:

• prompt_toolkit>=3.0.52,<4
• Python 3.11
• WSL (for Bug B)
• Background thread scenario (for Bug A)

[yonghuatrc]

Status Update (2026-05-10)

Partial fix shipped — guard merged at cli.py:1493.

What the fix does

Replaced deprecated with in to avoid the RuntimeWarning on Python 3.10+ when called from threads without a current event loop (e.g. the process_loop background thread). Fixes #19285 reference.

Remaining issue

The can still fire when is called from certain async contexts within the app loop. The inner in acts as a safety net — messages are never silently lost, they fall back to direct print.

Attempted wrapping to properly schedule the coroutine — architecturally correct but broke existing test fixtures (). Reverted pending a proper test refactor.

Test status

• — 11/11 passing

Next steps

Option A: Refactor the test fixture to support the path and re-apply the fix
Option B: Leave as-is with the reduced-warning state and document the edge case

Preference?

[mailinglistenator]

Resolved by disabling the feature

The confirmation dialogs introduced by these commits are broken for CLI users:

• 4d7fc0f37 — /reload-mcp confirmation
• b9c001116 — /new /clear /undo confirmation

Both call _prompt_text_input from the process_loop daemon thread. run_in_terminal() fails because the daemon thread has no asyncio event loop — the coroutine is orphaned and user input is silently lost, leaking into the agent buffer. Additionally, save_config_value depends on ruamel.yaml which is not in requirements.txt, so the "Always Approve" persistence path silently fails.

Workaround

Disable both features via config — set approvals.destructive_slash_confirm and approvals.mcp_reload_confirm to false. This skips the broken code path entirely.

Recommendation

Withdraw the feature until it has been tested on a real CLI (not just gateway button flows). The text-fallback path was never exercised before merge.

[teknium1]

Bug B (input prompt) is fixed in #23454 (commit c5f1f86) — _prompt_text_input now mirrors the thread-aware guard already in _run_curses_picker: when called off the main thread (i.e. from process_loop), it bypasses run_in_terminal and drives input() directly, so the prompt actually renders and consumes keystrokes instead of leaking them into the composer. Also added a try/except fallback for the WSL/Warp case where run_in_terminal silently drops the scheduled coroutine.

Five new tests in tests/cli/test_prompt_text_input_thread_safety.py cover: main-thread dispatch, background-thread fallback, no-app path, run_in_terminal-raises, and EOF handling.

One correction on the comment above: ruamel.yaml is a required dependency, not missing. It's pinned in pyproject.toml line 23 (ruamel.yaml>=0.18.16,<0.19); there's no requirements.txt in this repo. The "Always Approve" persistence path works on a clean install, so no need to disable the feature.

Bug A (_cprint orphaned-coroutine output loss) is separate — the existing fallback at cli.py:1517 keeps messages from being lost in practice; only the RuntimeWarning remains. Will track that as a follow-up. Closing this issue since the user-facing breakage (broken confirmation prompt) is resolved.

[yonghuatrc]

Local Fix Applied (2026-05-11)

Applied the _prompt_text_input fix from PR #23454 to local cli.py:

• Added threading.current_thread() is threading.main_thread() guard
• Added run_in_terminal exception fallback for WSL/Warp terminals
• run_in_terminal only called when self._app and in_main_thread
• Daemon threads fall back to direct input() — no orphaned coroutines

in_main_thread = threading.current_thread() is threading.main_thread()

if self._app and in_main_thread:
    from prompt_toolkit.application import run_in_terminal
    # ... use run_in_terminal
    try:
        run_in_terminal(_ask)
    except Exception:
        # WSL / Warp / certain terminal emulators silently drop the
        # scheduled coroutine. Fall back to a direct input().
        try:
            _ask()
        except Exception:
            pass
else:
    _ask()

Test status: tests/cli/test_cprint_bg_thread.py — 11/11 passing

This fixes Bug B (confirmation prompts swallowing keystrokes from daemon thread). Bug A (_cprint RuntimeWarning) remains — messages are never silently lost, only the warning fires.