[Feature Request] Modern text input: click-to-position, text selection, and standard editing in the prompt

Also want to add Ctrl+Shift+Left/Right Arrow for selecting whole words.

+1, this used to work few versions before, now the shorcuts for moving across words are switched, they work normally in iTerm but reversed inside CC

+1

+1

+1

+1 from a Windows user who just spent hours trying to solve this.

I went down a rabbit hole today trying to find a terminal where standard keyboard shortcuts (Ctrl+A, Ctrl+C/V,
Shift+Arrow) would work with Claude Code's input prompt. Here's what I tested:

1. VS Code integrated terminal (Git Bash) — configured custom keybindings, but Claude Code's Ink input handler

overrides them

1. Windows Terminal — Ctrl+C/V work at the OS level, but Claude Code's prompt intercepts keystrokes before the

terminal sees them

1. Warp — built specifically to solve this with a real text editor input. Works beautifully for regular terminal

commands. The moment you type claude, Warp's input gets bypassed by Claude Code's own Ink-based prompt handler

1. Wave Terminal — same result
2. JetBrains new terminal (block-based, text editor input) — same result. Their terminal rebuilt the input as an

IDE editor component. Claude Code overrides it.

1. PowerShell with PSReadLine — native Ctrl+A, Shift+Arrow all work perfectly... until you run claude

The irony: the only place these shortcuts work with Claude Code is the VS Code chat panel — because it bypasses the
Ink input entirely and uses a native text editor widget.

The Ink-based input is the bottleneck. No terminal can fix this from the outside. It needs to be fixed inside
Claude Code itself.

This is the single biggest UX gap in an otherwise incredible product. Every other text input on my computer —
browser, editor, notepad, even PowerShell — handles Ctrl+A, Shift+Arrow, and Ctrl+C as select/copy. Claude Code is
the only one that doesn't.

+1 Not sure if this has been covered elsewhere, but this also is affecting me on iOS. I’m simply trying to go to a spot that I typed previously in a long set of code and text description and I can’t go back. I can’t even select all to copy and paste it into text editor and edit it that way, and then re-paste it. I’m basically stuck with backspacing. I have an iPhone 16 Pro Max.

Windows-native keyboard shortcut gap (important complement to this feature request)

+1 on all points above. Additionally, on Windows Terminal + PowerShell, there's a specific muscle-memory gap with keyboard shortcuts:

Windows users expect these shortcuts to work (standard across every Windows app):

| Shortcut | Expected (Windows native) | Current behavior (Claude Code v2.1.92) |
|----------|--------------------------|----------------------------------------|
| Ctrl+A | Select all text in input | Goes to beginning of line (Unix readline) |
| Ctrl+Backspace | Delete previous word | Nothing / no effect |
| Ctrl+Delete | Delete next word | Nothing / no effect |
| Ctrl+Shift+Left/Right | Select word by word | Nothing / no effect |

Workaround: Windows users must learn Unix shortcuts (Ctrl+U, Ctrl+W, Ctrl+K), but they're non-intuitive when every other app uses Ctrl+A to select-all.

Suggested fix: When process.platform === 'win32', map these additional keybindings alongside existing Unix ones:

• Ctrl+A → select all (coexist with Ctrl+U behavior if needed)
• Ctrl+Backspace → delete previous word (alias for Ctrl+W)
• Ctrl+Delete → delete next word (new, complements Ctrl+K)
• Ctrl+Shift+Left/Right → select word by word (extension of selection)

Environment:

• OS: Windows 11 (10.0.26200)
• Terminal: Windows Terminal
• Shell: PowerShell 5.1.26100
• Node.js: v24.11.0

This would be a natural follow-up to the broader text-input improvements (mouse, click-to-position) mentioned in this issue.

Windows users expect these shortcuts to work (standard across every Windows app): Shortcut Expected (Windows native) Current behavior (Claude Code v2.1.92) Ctrl+A Select all text in input Goes to beginning of line (Unix readline) Ctrl+Backspace Delete previous word Nothing / no effect Ctrl+Delete Delete next word Nothing / no effect Ctrl+Shift+Left/Right Select word by word Nothing / no effect Workaround: Windows users must learn Unix shortcuts (Ctrl+U, Ctrl+W, Ctrl+K), but they're non-intuitive when every other app uses Ctrl+A to select-all.

In the Unix world—or virtually any terminal-based application—the standard keyboard shortcuts are:

• Ctrl+A: Move to beginning of line
• Ctrl+E: Move to end of line
• Ctrl+B: Move left
• Ctrl+F: Move right
• Ctrl+P: Move up
• Ctrl+N: Move down
• Ctrl+K: Delete characters to the end of line
• Alt+D: Delete word forward
• Ctrl+W: Delete word backward
• Ctrl+C: Interrupt

When using Claude Code inside a terminal, it is preferable to adopt these standard terminal keyboard shortcuts rather than requesting a terminal app to adopt Windows GUI keybindings conventions. Most terminal applications (e.g., IPython, Bash) running on Windows still follow the same Unix conventions. Claude Code can also run as a desktop GUI application, where standard GUI shortcuts apply as expected.

Evidence from binary analysis (v2.1.109)

I did some digging into the compiled binary to understand the current state of mouse support:

1. Mouse protocol infrastructure exists in the binary:

• strings scan of the v2.1.109 Mach-O binary finds \e[?1000h, \e[?1006h (SGR mouse enable sequences)
• Also found MouseClick, MouseDown, MouseClickDrag, setMousePosition identifiers — suggesting the TUI framework (likely Ink/React-based) has mouse event scaffolding

2. But it's never activated at runtime:

I used expect to allocate a pty, launched Claude Code, and captured the raw terminal output during TUI initialization. Tested 6 environment combinations:

| Scenario | Enable sequences (h) | Disable sequences (l) |
|---|---|---|
| In tmux, TERM=tmux-256color | 0 | 4 (1000l, 1002l, 1003l, 1006l) |
| In tmux, TERM=xterm-256color | 0 | 4 |
| In tmux, TERM=xterm-ghostty | 0 | 4 |
| No tmux, TERM=tmux-256color | 0 | 4 |
| No tmux, TERM=xterm-256color | 0 | 4 |
| No tmux, TERM=xterm-ghostty | 0 | 4 |

Claude Code actively sends disable sequences (\e[?1000l etc.) on startup to reset terminal mouse state, but never sends the corresponding enable sequences. This is consistent across all TERM values and regardless of whether $TMUX is set.

3. tmux-side confirmation:
tmux display-message -p '#{mouse_any_flag}' returns 0 for the Claude Code pane, confirming no mouse tracking was requested.

Environment: macOS 14 / Apple Silicon, Ghostty terminal, tmux 3.x with mouse on + allow-passthrough on, Claude Code CLI v2.1.109.

This suggests the rendering framework already has the plumbing — it just needs to be wired up. Hope this helps prioritize!

+1
Clicking to reposition the cursor within a long prompt -- how can this not be supported yet.

+1 — and a narrower ask within this: please expose a chat:selectAll action in the keybindings system (~/.claude/keybindings.json), so users who want Emacs-style bindings can map C-x h (and similar chords) to select-all in the chat input.

The proposed behavior table here lists Ctrl+A as the default, which is great. But the keybindings reference doesn't currently include any selection action for the Chat context — only the Scroll context has selection:* actions, and those are for selecting text in scrolled output, not the input field. That means even once Ctrl+A lands, there's no way to rebind it.

Concretely, what's needed:

• A new chat:selectAll action (default: Ctrl+A)
• Probably also chat:copy, chat:cut, chat:paste (currently only chat:imagePaste exists), so the whole selection/clipboard flow is rebindable

This would let people configure things like:

{
  "context": "Chat",
  "bindings": {
    "ctrl+x h": "chat:selectAll"
  }
}

+1, same pain on Windows 11 + VS Code integrated terminal + PowerShell pwsh.

Concrete reproduction:

• In bare pwsh (no claude running): Ctrl+A works perfectly — PSReadLine.SelectAll highlights the entire prompt line. Standard expected behavior.
• The moment I run claude and focus moves into the Claude TUI input, Ctrl+A is hardcoded to BeginningOfLine (Ink/readline default), and there's no way to select-all my typed input.

I tried adding "ctrl+a": "chat:selectAll" to ~/.claude/keybindings.json — the action doesn't exist in the configurable list (chat:cancel, chat:submit, chat:externalEditor, chat:clearInput, etc.). Confirmed via the keybindings-help skill — selectAll is not exposed at the config layer.

Ctrl+G (chat:externalEditor) works but, as the original report says, it's disproportionate overhead for what should be a 1-keystroke interaction. The proposed Ctrl+A behavior in the table above is exactly what's needed.

+1

+1

Ink repaints the whole frame each update, so SGR mouse coords don't map to a cursor index without your own hit-testing per render.

+1

+1

To the purists that insist that every user must adopt the terminal input model instead of the standard word processing text input model that has been used for 30 years by 99.999% (5 nines here) of the rest of the 8 billion people on the planet, I say why must that be the case?

As Claude (and all other AI and related toolsets) move outside of the traditional "coder" world, a unified configurable option across PSH, bash, CC, and Claude.ai (and all the rest of the AI and tool interfaces), that allows a user to change the style of input modalities would be and elegant and inclusive way to continue to democratize application development.

+1

Adding a verified diagnosis, since the closed duplicates (#25047, #27835, #41166) keep pointing here and going stale.

What I verified on macOS (Ghostty 1.3.2, cmux, and the iTerm2 report in #41166):

• Option+click cursor positioning works fine at a shell prompt. Terminals implement it there through shell integration. Ghostty 1.3 even supports shell-native OSC 133 click events.
• It can never work in the Claude Code composer from the terminal side. Both terminal mechanisms (synthetic arrow keys and OSC 133 click events) are scoped to shell prompts. Only the app knows the composer's text layout.
• In iTerm2 the synthetic-arrow fallback partially leaks through and moves the cursor one character per click (#41166). The terminal is trying. The input handler just can't map it.

On feasibility: Claude Code already consumes mouse events for the autocomplete menu and in fullscreen mode, so the mouse-reporting plumbing exists. The remaining work is mapping SGR click coordinates to a composer text position when option is held. The modifier bit is already part of the SGR encoding. Gating on option preserves plain-click text selection.

Editing long prompts is the slowest part of using the tool today. Word-jump keys help, but click-to-position is the muscle memory every terminal trained us on.