[BUG] Composer silently loses a span of typed text from a long prompt before submit, with no way to recover it

Summary

Bug: the CLI prompt composer silently lost about 800 characters of typed text from the middle of a long (about 11,000 character) prompt before it was submitted, and nothing in Claude Code kept a copy, so the text could not be recovered.

Expected behavior

Text the user types into the composer is never lost without the user acting. The composer keeps a recoverable copy of the draft at all times, and in particular before and while it collapses or truncates a long draft, so any deleted or dropped content can be brought back, including after submit and after a restart.

For long input, Either of the following:

1. Remove the composer input limit, so a long draft is never truncated.
2. If a hard limit has to stay, split over-limit input into several prompts on submit instead of discarding or hiding any of it.

Actual behavior

A long multi-section prompt, mostly typed replies between quoted sections, was submitted with a contiguous span missing from the middle. One paragraph ends mid-sentence with the exact characters (but not the and continues directly with the next section's separator line. The rest of that paragraph and the whole following paragraph, about 816 characters by the author's reconstruction from memory, never reached the model. There was no warning, no error and no visible sign of the loss before submit.

Two lines below the cut, a stray /compact was glued to the end of a quoted heading (...may provision/compact). The quoted source heading did not contain /compact; it was added inside the composer.

Once the draft passed about 10,000 characters, the composer had folded its middle behind a placeholder, so the author could not see or re-read that part before submitting. After submit, the sent message was also displayed with a (30 lines hidden) fold.

Impact: long, carefully written prompts are the hardest to reconstruct, and the loss was found only because the receiving session noticed a sentence ending mid-way. A cut that fell on a sentence boundary would have gone unnoticed by both the user and the model.

Minimal reproduction

Not yet reproduced on demand. The workflow that produced it:

1. Start an interactive session with the fullscreen renderer (tui: fullscreen) and the default editor mode.
2. Compose one long prompt in the composer, top to bottom: short quotes (two or three lines each) copied from the session's own earlier output, each followed by a typed reply, until the draft passes 10,000 characters. The composer then shows the start and end of the draft with the middle folded.
3. Keep typing at the end, paste a screenshot with Ctrl+V, then submit.
4. Observed: a span of typed text from the middle of the draft is missing from what the model received, and an unrelated /compact token appears two lines below the gap.

Environment

• Product and version: Claude Code CLI 2.1.283
• OS and version: Ubuntu 22.04.5 LTS, Linux 6.8.0-1066-aws #69~22.04.1-Ubuntu SMP, x86_64
• Model / resolved model ID: us.anthropic.claude-opus-5-5[1m]
• Runtime context: Linux cloud VM reached over VS Code Remote SSH; VS Code integrated terminal running tmux; fullscreen renderer; long-lived interactive session
• Authentication/provider path: Amazon Bedrock

Diagnostics

All measured read-only from Claude Code's own local files after the incident:

• The received user message is one text block of 11,265 characters plus one image block. It ends the affected paragraph with (but not the followed by a newline and the next section.
• The prompt-history entry stores the prompt as 2,309 display characters with one [...Truncated text #3 +62 lines...] placeholder. Its paste-cache file holds 8,991 characters. Replacing the placeholder with that content reproduces the transcript text exactly (same length, same SHA-256), so history, paste cache and transcript all agree on the damaged text.
• Phrases from the missing text appear in no prompt-history entry and no paste-cache file on the machine. A control phrase from the sent text is found in both, so the search works.
• The visible part of the folded draft is 500 characters before the placeholder (plus a 10-character image chip) and 1,764 after it. Two earlier long prompts on the same machine show 500 before and 500 or 568 after, with totals just over 10,000 characters. That suggests the composer folds a draft past about 10,000 characters to its first and last 500 characters, and that here the fold happened while the last section was being typed. The folded middle already lacked the missing text and already contained /compact.
• The screenshot's [Image #2] chip landed at character 500, mid-phrase (as i[Image #2] asked), exactly at the fold boundary. The intended spot, here's the screenshot: go ahead with a double space, is inside the folded middle.
• The (30 lines hidden) fold in the sent message covers a different range from the composer placeholder and is display only: the session received every character in that range.
• The prompt was 11,265 characters, far below the 50,000-character message cap reported elsewhere, and carries no [Message truncated marker.

Regression and controls

• Fresh process/session: not tested.
• Last known good version: unknown.
• Relevant control: the CLI's own prompt history, paste cache and transcript agree byte for byte on what was sent, which rules out a placeholder failing to expand at submit and a transport-level truncation. The loss happened inside the composer buffer before the text was frozen.

Hypothesis

Reporter analysis, not observed behaviour. The deletion is a clean contiguous span that ends at a line boundary, with an unrelated /compact inserted two lines below it. That fits an editing or completion event in that region (for example a mid-prompt / completion accepted with Tab or a click in the fullscreen renderer, or a run of delete-to-end-of-line presses) better than a size cap or a paste race. Whatever the trigger, the folded middle meant the author could not see the damage before submitting, and no recovery path existed afterwards: undo and Ctrl+Y only work before submit, and the Ctrl+S stash and double-Esc draft save are manual.

Related public reports

1. https://github.com/anthropics/claude-code/issues/74004: a very long typed message silently truncated before reaching the model. Closest symptom; no mechanism identified there.
2. https://github.com/anthropics/claude-code/issues/90910: a long prompt silently truncated from the start; the loss happens before Claude Code records the input, as here.
3. https://github.com/anthropics/claude-code/issues/92118: large messages cut at 50,000 characters with no warning; a commenter asks for an offer to split and for the overflow never to be discarded.
4. https://github.com/anthropics/claude-code/issues/24431: chunks silently dropped from the middle of a pasted block. Mid-text loss like this one, but on the paste path.
5. https://github.com/anthropics/claude-code/issues/87017: text typed in the external editor (Ctrl+G) destroyed and replaced by a placeholder on return.
6. https://github.com/anthropics/claude-code/issues/5017: pasted multi-line text truncated, with a reproduced 800-character boundary in the comments.
7. https://github.com/anthropics/claude-code/issues/94063: the Ctrl+S stash, the only built-in place to park a draft, is not restored after exit and resume.
8. https://github.com/anthropics/claude-code/issues/75663: a stashed prompt lost when a background agent goes cold.
9. https://github.com/anthropics/claude-code/issues/99252: the user's own long message folded as (N lines hidden) in the transcript and not expandable or copyable.
10. https://github.com/anthropics/claude-code/issues/55617: pasted text lost when the CLI truncated an extra-long prompt (closed as completed).
11. https://github.com/anthropics/claude-code/issues/99399: part of a long draft drawn invisibly while typing in a half-switched fullscreen session.
12. https://github.com/anthropics/claude-code/issues/85924: queued composer text silently discarded on mobile.