[BUG] Large dictated paste reassembled out of order in TUI — mid-word chunk splices (macOS, iTerm2, Wispr Flow)

Status Open
Reported on v2.1.220
Maintainer reply None cached
Activity 0 comments · opened Jul 29, 2026

Environment

  • Claude Code: 2.1.220 (CLI in iTerm2)
  • iTerm2: 3.6.6
  • macOS: Sequoia (Darwin 24.5.0)
  • Input source: Wispr Flow voice dictation (injects transcribed text into the focused field; splits long dictations into multiple chunks — see their docs on Claude Code handling)

Symptom

A long dictated message (~4,000 chars) arrived in the prompt silently reordered: the message was split into 4 chunks (call them A, B, C, D in true order) and submitted as B, C, A, D. The splice points fall mid-word ("patte|rn", "tha|t was possible"), so the chunk boundaries are byte offsets, not line or sentence boundaries. No error, no indication anything was mangled — the reordered text was submitted as-is.

On other occasions the same setup has dropped the leading chunk entirely (message arrives starting mid-sentence), which looks like the same failure with the displaced chunk lost instead of spliced late.

Reconstruction (real example, 2026-07-29)

True order (as dictated):

[A] "Okay, I want to think through this aspect of the system. ... to shift them out of the patte"
[B] "rn they're in into a better one, which will have positive externalities. ... more or less, right?"
[C] "I'm thinking about this. ... they would be like, 'Well, how'd you do it that fast? I didn't know tha"
[D] "t was possible,' and then they would serve me. It all comes back to ..."

Received order: B, C, A, D — i.e. the first chunk was re-queued behind the next two, then the stream resumed correctly.

Hypothesis

Rapid successive synthetic paste events (Wispr Flow's chunked injection) race Claude Code's TUI input reassembly. The mid-word offsets and the clean 4-way segmentation suggest the chunks arrive intact but are dequeued/appended out of order. Possibly related to how bracketed-paste segments are buffered and merged into the prompt ([Pasted text #N] handling).

Related issues (same cluster, none capture the reordering)

  • #25557 — pasted text silently truncated, beginning dropped (tail-only arrival = this bug with the displaced chunk lost?)
  • #51129 — long paste truncates/corrupts across sessions (closed duplicate)
  • #38620 — Wispr Flow simulated Ctrl+V broken on Windows since v2.1.83
  • #39983 — Wispr Flow simulated Enter not registered in raw mode (macOS)

Repro direction

Inject a >3 KB paste as several rapid sequential synthetic paste events (timing like Wispr Flow's chunk injection) into the TUI prompt; compare received prompt text to source. Expect order inversion or leading-chunk loss under tight inter-chunk timing.

---

Reported by @edobry. Investigation, forensic reconstruction, and drafting done with Claude (Claude Code session); the reordering evidence is from a real captured prompt.

View original on GitHub ↗