[BUG] Long prompt silently truncated from the start on macOS/Warp: 762 of 2,211 characters delivered, cut mid-word

Independent confirmation with a mechanism narrowed down, from a machine that hits this at scale. No message content included (internal), but the structure is fully characterized.

Mechanism observed: when a large text block is delivered into the composer — a human Cmd+V through a terminal, or automated typing (tmux send-keys from an agent-orchestration tool) — it arrives at the TUI in ~1KB chunks. The composer folds the first chunk into a [Pasted text #1 +N lines] attachment and appends the later chunks inline after the placeholder. Intermittently the attachment's content is dropped at submit, so the model receives only the inline tail — a prompt silently truncated from the start, cut mid-word, exactly as this issue describes.

Key evidence:

• Deterministic cut point per payload. A 1270-byte plain-UTF-8 text (no control characters) cuts at byte 1022 every time it cuts — the chunk boundary is fixed for fixed content. The visible composer state right before a failing submit shows [Pasted text #1 +8 lines] followed by the inline tail.
• Intermittent, ~2/3 for that payload. Re-pasting the identical clipboard sometimes goes through whole (attachment expands correctly), sometimes tail-only.
• Receiver-side, not transport. Same clipboard pasted into another app is always intact; OS pasteboard round-trips are 100/100 clean. On this machine, automated cross-session messages arriving at Claude Code panes land tail-only in 38% of observed arrivals (n=361 over 5 days) vs 7% on Codex CLI panes receiving comparable traffic (n=30) — the delta points at the paste-folding path, not the pipe.
• Likely the same defect as the paste-truncation half of #86954.

Env: Claude Code 2.1.258, macOS 26.4, tmux 3.6a panes managed by an orchestration app (dev-3.0), ~25 concurrent sessions (load appears to amplify the failure rate). Happy to run diagnostics on request — this machine reproduces it daily.

same here. just updated from 2.1.220 and all heck broke loose.
The following from one of my Claude agents:

Independent reproduction on a second fleet, with two controls I have not seen posted here: the
transport is clean, and the version boundary is pinned by binary size rather than --version.

Environment: macOS, tmux 3.6a, ~10 concurrent Claude Code sessions in tmux panes, each receiving
messages injected by an external process via tmux send-keys. Symptom is exactly as described —
head silently dropped, contiguous tail retained, no error anywhere.

1. The bytes reach the pane intact. The loss is above the PTY.

A raw-mode PTY reader on the affected machine, fed through the identical tmux send-keys path
used for real deliveries, with a 3000-byte payload:

captured 3003 / 3000 bytes — starts ETE.

The same 3000 bytes delivered to a live Claude Code session on that machine arrived as its final
~36 bytes. Six further trials with t0–1.10 s apart) also captured both
bodies intact at the PTY, with no interleaving.

So tmux, the PTY, and the sending path are all exonerated on the machine that fails. Whatever
discards the prefix is in the application reading the pane.

2. Version boundary, pinned by size match against the npm cache

claude --version reports the installed binary, not the image a running process — this
misled three of our sessions into reporting themselves as a newer version than they were running.
We matched each running process's mapped executable by inode and size instead:

2.1.220   256,908,272   never truncates   (verified against npm cache tarball)
2.1.227   285,046,400   never truncates   (independently measured on a second host)
2.1.252   197,220,928   truncates

Same host, same delivery path, same byte-identical payload across all three. Two sessions on 2.1.252
truncate; three sessions on 2.1.220/2.1.227 did not, across 68+ multi-KB messages.

Caveat, stated because it matters: given the ~38% intermittency already reported here, a clean
run of N is weak individually — 3 clean arrivals has a ~24% chance of occurring on an affected
build. The boundary rests on the consistency across three receivers, not on any one of them.

3. The cut offset is deterministic given the same input

Three arrivals of one byte-identical 3000-byte payload, two senders, two hosts, all cut at the
identical token. On a 999-byte payload (1138 bytes once JSON-enveloped) the surviving tail was 116
bytes — 1138 mod 1022 = 116, exact. One of the agents predicted the surviving token of an
unsent probe in advance; it landed one byte off.

So: the cut LOCATION looks deterministic in the input length, while WHETHER it cuts is
intermittent — consistent with a fixed-size read boundary plus a race on the placeholder.

4. Why this is data loss rather than a display bug

The tail alone frequently reads as a complete short message. We caught it only because breaks landed
mid-word. In one case the discarded head contained the answer to a safety question that had been
asked, and the recipient would have proceeded without it had the break fallen one sentence later.

Workaround

We stopped injecting bodies entirely: the sender now writes the message to a file and injects only a
short fixed-length pointer, well undee-line fold threshold. That is
reliable across all versions tested.

Note for anyone applying that threshold: the rule is 800 characters OR more than three lines, and
the line arm fires far earlier in practice. Across 151 of our machine-generated payloads: zero
exceeded 800 bytes; 151 of 151 exceeded three lines, minimum 17. A byte-only guard clears the
commonest case.

A related case is now filed as https://github.com/anthropics/claude-code/issues/100955. On Claude Code 2.1.283, about 800 characters of text the author typed vanished from the middle of an 11,265-character prompt before submit, far below the 50,000-character cap. Claude Code's own prompt history, paste cache and session transcript all agree byte for byte on the damaged text, so the loss happened inside the composer before anything was written, and no local copy survives to recover it from.