[BUG] Image-paste separator space survives Shift+Enter and lands at the start of the next line

Status Open
Reported on v2.1.259
Maintainer reply None cached
Activity 0 comments · opened Sep 3, 2026

Version: 2.1.259, native install, Linux (WSL2), Windows Terminal

Repro

  1. Paste an image into the prompt (Ctrl+V).
  2. Press Shift+Enter.
  3. Type anything.

Actual — the typed text is preceded by a stray space:

Here is the dialog: [Image #1]
 And now it shows ...

Expected — no space, or at least a separator space adjacent to the placeholder it separates.

It survives any number of newlines, so two Shift+Enters still yield one orphaned space in front of whatever is typed next.

Cause

Pasting an image does not insert a separator space; it sets a pending flag, and the next typed input gets the space glued on:

if (!UK.current) return _Z;
UK.current = false;
if (PZt(_Z, f5n) && !DZt(_Z)) return " " + _Z;
return _Z;

(PZt declines when the input already starts with whitespace or carries ctrl/meta; DZt declines on .,?!:;)]. Either way the flag clears.)

The newline command never reaches this transform, so it neither consumes the pending space nor clears the flag. The exclusion set the transform consults does list "return" and "enter", which suggests a newline was meant to pass through and clear the flag harmlessly — it doesn't arrive there at all. The space instead attaches to the first character typed after the newline, on a line where a separator means nothing.

Workaround

Press Space (or one of .,?!:;)]) immediately after the paste — both clear the flag without injecting anything.

Impact

Every "paste screenshot, newline, describe it" message picks up a leading space that has to be deleted by hand.

View original on GitHub ↗