[BUG] Vim mode: after a paste, Shift+Enter intermittently submits instead of inserting a newline (Ghostty/macOS, stock keytab)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

With editorMode: "vim", after pasting content into the composer, Shift+Enter intermittently submits the prompt instead of inserting a newline. It usually bites while opening up a blank line — press Shift+Enter twice and the turn gets sent mid-composition, taking the paste and a half-written prompt with it.

Three things separate this from the existing Shift+Enter reports:

1. A paste is required. With typed-only input, Shift+Enter inserts a newline every time. I cannot reproduce it without a paste in the buffer. So this is not the usual terminal-keytab story — Ghostty speaks the Kitty keyboard protocol and Shift+Enter is delivered correctly here under all other circumstances. That rules it out as a duplicate of #74056 (Apple Terminal, every press submits) and #72299 (Konsole, keytab limitation).
2. It is intermittent. After a paste, some Shift+Enter presses insert a newline and some submit. It is not reliably "the second press".
3. Vim mode is on. This may well be the discriminator — see the hypothesis below.

The failure is destructive and unrecoverable: an unfinished prompt is sent, and the composer is cleared before you can react.

What Should Happen?

Shift+Enter should insert a newline while the composer has focus, regardless of whether the buffer contains pasted content and regardless of which vim mode the editor is in. A paste should not be able to change what Shift+Enter does.

If Shift+Enter is intentionally submit-in-NORMAL-mode, then the defect is that a paste silently moves the editor out of INSERT with no visible signal — the user has no way to know the key's meaning just changed under them. (#85078 is the feature request for making this mode-aware and configurable; this report is about the paste-triggered, unsignalled transition.)

Error Messages/Logs

# No error output — the prompt is simply submitted.
# Observable symptom: the composer clears and a turn starts with a
# half-written prompt, instead of a blank line appearing in the input.

Steps to Reproduce

1. Set "editorMode": "vim" in ~/.claude/settings.json.
2. Open Ghostty (stock config, no custom keybinds) on macOS and run claude.
3. Type a line of prompt text.
4. Paste a block of content into the composer (Cmd+V).
5. Press Shift+Enter a couple of times to open a blank line before typing more.
6. Intermittently, one of those presses submits the prompt instead of inserting the newline.

Repeat a few times — it does not fire on every attempt.

Not reproducible with the same steps minus step 4 (compose multi-line input with Shift+Enter, no paste anywhere) — that works consistently.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.237 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

Environment

• Claude Code 2.1.237, native installer (~/.local/share/claude/versions/2.1.237)
• macOS 15.6 (24G84), Apple Silicon
• Ghostty 1.3.2-HEAD-+6143bac, TERM=xterm-256color, TERM_PROGRAM=ghostty
• Ghostty config contains only font-family, font-size, working-directory — no custom keybinds
• No ~/.claude/keybindings.json — entirely stock Shift+Enter handling
• "editorMode": "vim" in ~/.claude/settings.json
• Not inside tmux/screen ($TMUX and $STY both unset); not the VS Code or JetBrains integrated terminal

Primary hypothesis: the paste drops the editor out of INSERT mode (not verified)

The most likely mechanism is that finishing a paste leaves the vim editor in NORMAL mode — or that some part of the pasted byte stream is interpreted as NORMAL-mode input rather than literal text — after which Shift+Enter takes the submit path instead of chat:newline. That would explain all three observations at once: the paste precondition, the intermittency (it would depend on paste content and on where the mode transition lands), and why it never happens with typed input.

There is precedent for paste bytes being interpreted as vim commands rather than text: #73098 (closed) reported that in vim editor mode, pasted line breaks become a literal j when the paste is not bracketed — the same class of failure, newlines in a paste being read as NORMAL-mode keystrokes instead of content.

One-step check for whoever triages this: paste into the composer and look at the vim mode indicator immediately afterwards. If it reads NORMAL rather than INSERT, this is deterministic rather than intermittent, and the fix is to keep (or restore) INSERT across a paste. I am happy to run that check and report back.

Alternative hypothesis: collapsed-paste state (also not verified)

I did not vary paste size, so I cannot rule out that the failures correlate with the paste collapsing into a [Pasted text #N +M lines] placeholder. If they do, this may share a root cause with #85654, where a slash command inside a collapsed paste is not dispatched and falls through to the ordinary submit path — i.e. key handling changes while the buffer holds a placeholder rather than literal text. #85453 documents the collapse thresholds (~800 characters or more than 3 lines), which would also fit the intermittency.

What I did not vary

Vim mode on/off (editorMode: "normal" untested), paste size and collapse state, pane width, terminal (only Ghostty), Claude Code version (no bisect — I do not know when this started).

Related issues

• #73098 (closed) — vim mode, paste line breaks interpreted as a literal j; closest known precedent for paste bytes being read as NORMAL-mode keys
• #85078 — [FEATURE] vim-mode-aware keybinding contexts, enter newline in INSERT and submit in NORMAL
• #2588 — Enter key behavior in vim INSERT mode for prompt submission
• #85654 — slash command inside a collapsed [Pasted text #N] is never dispatched, takes the submit path instead
• #85453 — paste collapse thresholds (~800 chars or >3 lines)
• #45998 (closed) — paste itself auto-submits when the clipboard ends with a newline; here the submit happens on a later Shift+Enter, not on the paste
• #74056, #72299, #77311 — Shift+Enter submits unconditionally in specific terminals; different cause, since Shift+Enter works here without a paste
• #81472 — [META] copy/paste tracking issue