[BUG] Run button echoes a corrupted command: input line overflow wraps to column 0 and overwrites the start instead of wrapping to a new row
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Clicking the Run (▷) button on a bash code block echoes a corrupted command into the terminal input when the command is longer than the input line's visible width. The overflow wraps to column 0 and overwrites the start of the line instead of wrapping onto a new row.
The corruption is exactly characterizable as a modulo-width overwrite, not a truncation or a scrambled paste.
Code block clicked (36 chars):
cd android && ./gradlew installDebug
Echoed into the input (34 chars):
ug android && ./gradlew installDeb
Characters 34–35 (ug) overwrote indices 0–1 (cd). Everything between is untouched and in original order. Reproduced programmatically against a fixed-width buffer:
orig = "cd android && ./gradlew installDebug" # 36
seen = "ug android && ./gradlew installDeb" # 34
W = 34
buf = list(orig[:W])
for i, ch in enumerate(orig[W:]):
buf[i % W] = ch # wraps to index 0 instead of a new line
assert "".join(buf) == seen # passes
Only W = 34 reproduces it, and it reproduces exactly.
The practical hazard is that the result stays syntactically plausible. Here the mangled line happens to be harmless — ug is not a command and && short-circuits, so the ./gradlew half never runs. But the same wrap on a command whose leading token is replaced by valid characters rather than broken ones would silently run something other than what the code block showed. A cd somewhere && rm -rf build losing its cd is the shape of the problem.
One thing I could not determine: whether the underlying input buffer is corrupted or only the render. I did not submit the line. #81175 reports that for the typed-input path "the input buffer itself stays correct, only the render is wrong" — if that also holds here, this is cosmetic-but-alarming rather than dangerous. If the buffer is corrupted too, it is a wrong-command-execution bug. Worth confirming, since severity depends entirely on which.
What Should Happen?
The Run button should place the command in the input verbatim, wrapping onto additional rows when it exceeds the visible width. The echoed text should be byte-identical to the code block's contents at any terminal width.
Related
- #81175 — input line renders one column left (per-keystroke, leading-backspace vs. absolute cursor parking). Same subsystem, different trigger and different mechanism; this one is a bulk insert wrapping at a fixed width rather than a per-character off-by-one. Possibly a shared root cause in input-line rendering, but the signatures do not match.
- #88793, #89602 — other Run-button issues, unrelated symptoms.
Environment
- Claude Code 2.1.207
- macOS 15.7.4 (24G517), x86_64
- Observed in the Claude Code desktop app's integrated terminal
- Input line width at the time: 34 columns