Problem

On Windows, pressing Up on an empty composer scrolls the transcript instead of navigating to the previous submitted message. Typing even a single character and pressing Up correctly navigates input history — but an empty composer does something completely different.

This is confusing and inconsistent. The user expectation is: Up on an empty composer = recall my last prompt.

Root cause

default_composer_arrows_scroll_for_platform in app.rs returns is_windows || !use_mouse_capture. This forces composer_arrows_scroll = true on all Windows machines, even on modern terminals like Windows Terminal that fully support mouse capture.

The composer_arrows_scroll feature was introduced in #1211 for terminals that map mouse-wheel events to arrow keys (e.g. CMD.exe without WT_SESSION). When composer_arrows_scroll = true and the composer is empty, Up/Down scrolls the transcript rather than navigating history.

But the blanket Windows override (is_windows ||) applies this workaround to terminals that don't need it.

Expected behavior

• Mouse capture ON (Windows Terminal, most terminals): Up/Down on empty composer navigates input history
• Mouse capture OFF (CMD.exe, terminals without mouse support): Up/Down scrolls transcript (mouse-wheel-as-arrow fallback)

Proposed fix

Change the default to !use_mouse_capture only, removing the is_windows || platform check:

fn default_composer_arrows_scroll_for_platform(use_mouse_capture: bool, _is_windows: bool) -> bool {
    !use_mouse_capture
}

Users who prefer the old scroll-on-empty behavior can explicitly set composer_arrows_scroll = true in their config.toml.

Related

• composer_arrows_scroll introduced in fix(tui): scroll transcript when composer is empty, not history #1211
• Windows mouse-wheel fallback added in Page flipping function abnormal #1443, PR Recovered diff from Hmbown/DeepSeek-TUI#1443 #1471
• Config docs state default is false