[Bug] Claude Code CLI truncates long input messages without warning

The frustrating part here is the silence — the input is cut before it reaches the model, and nothing tells you it happened, so you only find out when the reply answers a truncated version of what you wrote. Two things that help while the client-side limit stands:
Bypass the input widget entirely for long content. The truncation is in the interactive TUI input box, not on the file/stdin path. So for anything long, don't type it into the prompt — put it in a file and point Claude at it:

• Interactive: save the text to e.g. /tmp/msg.md and send just read /tmp/msg.md and do X. The Read tool has no ~120-line prompt-box limit, so the model sees the whole thing.
• Non-interactive: claude -p "$(cat /tmp/msg.md)" — piping through stdin doesn't go through the input widget.
• Pasting long blocks (vs typing) also routes differently in most terminals, but the file path is the reliable one.

Confirm nothing was dropped when it matters. After sending a long message, a quick how many lines/characters did you receive in my last message? will surface a mismatch immediately, before you build on a truncated request. Crude, but it turns a silent cut into a visible one.
Neither of these is the real fix — that's on the client side: either don't silently discard input, or show a visible "message truncated at N lines" indicator so the loss is never invisible. A long, carefully-typed message being cut with zero feedback is the worst version of this because the cost (re-typing, or worse, not noticing) lands entirely on the user. But until that indicator exists, composing long input in a file sidesteps the limit completely rather than fighting it.
(If you can reproduce it, the line count where it cut — you mention ~121 lines — is useful signal for whoever fixes this; it suggests a fixed buffer/row cap in the input widget rather than a byte limit.)

The same happened to me last night and made claude not behave as expected for the overnight job. Despite the inconvenience, I would rate this issue as critical. I am using VSCode with the claude code plugin and our application is not critical, but imagine you are using claude code agent in a critical infrastructure or any sensitive use case and parts of your prompt are silently omited. I don't even want to thing what would happen to autonomous defense/weapon systems having such an issue.

In my case the prompt looked like:

Background information and goal...
A long log content (over 100k chars)
Further instructions and details...

So basically only half of the agent instructions was processed. This is even how I found out that something was missing, because the agent did not create the requested protocol (md file) of what it fixed, which was part of the details.

It was easy to work around this by just putting the log data in a file and not having it pasted in the message. So I now know how to circumvent this issue. But learning by accident or documentation is not sufficent in my opinion.

I would expect that either the whole message is processed or nothing. So when my data exceeds 50k chars, I must not be able to submit it, but instead get an error message. Silent truncation is dangerous!

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.