UX: Slash command menu selects wrong command when using arrow keys after partial match

Describe the bug

When typing a partial slash command that matches a specific item, the menu highlights the correct match — but pressing the down arrow key to \"confirm\" or \"navigate to\" it instead moves the selection to the next item in the list, which then executes unintentionally.

Steps to reproduce

1. Start typing /co in the input — the menu highlights /context (correct match)
2. Press the down arrow key, expecting to select/confirm the highlighted item
3. The selection moves down to the next command (/clear)
4. Press Enter — /clear runs instead of /context

Expected behavior

• The down arrow should move selection within the filtered list in a predictable, clearly communicated way
• Critically: /clear should require a confirmation prompt ("Are you sure? This will erase your conversation and cannot be undone.") given how destructive and irreversible it is

Actual behavior

/clear executed silently and immediately, erasing the entire conversation with no warning and no way to recover.

Why this is high severity

/clear is the most destructive command in the CLI and the only one with no undo. A single accidental keypress — very easy when navigating a menu — permanently destroys conversation context that may represent significant work. All other destructive actions in modern CLIs (e.g., git reset --hard, rm -rf) are either prompted or at minimum require deliberate additional input.

Suggested fixes

1. Add a confirmation prompt to /clear: "This will erase your conversation history. Continue? [y/N]" — this alone would have prevented the data loss.
2. Fix arrow key UX in the slash menu: Typing a partial match and pressing down should not jump past the matched item to a destructive command.
3. Consider renaming or visually separating /clear from other commands in the menu to reduce proximity to /context.

Environment

• OS: macOS Darwin 25.2.0
• Shell: zsh
• Claude Code version: 2.1.71