Vim mode: / and ? are bound unconditionally, so they cannot search within the input and ? draws the help popup over it

Summary

In Vim mode, / and ? in NORMAL mode are bound unconditionally to non-editing actions, so they cannot be used to search within the input as they would in Vim:

• / opens reverse history search
• ? opens the help menu, drawing a popup over the input

The / binding is deliberate — the v2.1.152 changelog describes it as matching bash/zsh vi-mode. The problem is that both bindings fire regardless of whether the input already has content, so pressing either key while composing a prompt interrupts editing rather than searching within what you have typed. With ? the interruption is worse than nothing, because a popup menu is drawn over the text you were working on.

Steps to reproduce

1. Enable Vim mode (/vim).
2. Type a multi-line or long prompt into the input.
3. Press Escape to enter NORMAL mode.
4. Press / — reverse history search opens instead of an in-input search prompt.
5. Press ? — the help menu opens over the input instead of a reverse in-input search prompt.

Expected behaviour

In Vim, / and ? search forwards and backwards within the text being edited. That is decades-old, near-universal muscle memory for Vim users, and it is what a Vim mode implies.

Suggested behaviour: make the bindings conditional on input content

Rather than removing the existing shortcuts, gate them on whether the input is empty:

• Input has content, NORMAL mode: / and ? search forwards and backwards within the input, as in Vim.
• Input is empty: / and ? keep their current behaviour — reverse history search and the help menu.

This keeps Vim mode consistent with the non-Vim case rather than introducing a new rule. Without Vim mode there is effectively no way to trigger the help menu while the input has content, because typing ? just inserts the character. Gating on an empty input preserves that same relationship, so nothing is lost for users who rely on the current shortcuts, while / and ? become usable for their conventional purpose when there is text to search.

Ctrl+R already provides history search independently, so the / shortcut is a convenience rather than the only route to that feature.

Why this is not user-fixable today

~/.claude/keybindings.json cannot address it:

• There is no Vim-mode context among the bindable contexts, so a binding cannot be scoped to NORMAL mode.
• There is no in-input search action to bind to — the available search actions are history:search and settings:search, neither of which searches the input buffer.

Related

• #62670 (closed) and #70705 (open) both concern documenting the / history-search mapping, and note the v2.1.152 changelog entry describing it as matching bash/zsh vi-mode. Neither covers ? or in-input search.
• #66797 (closed) requested Vim-style in-chat search for the Claude Desktop Chat app, not the CLI.

Environment

Claude Code 2.1.220, macOS (darwin arm64), Vim mode enabled.