[BUG] Paste into prompt is inserted twice, concatenated byte-identically — doubled command is then EXECUTED on ! bash-input (2.1.220, macOS, tui: fullscreen)

Summary

Pasting into the prompt inserts the pasted text twice, concatenated with itself, byte-for-byte, with no separator. On ! bash-input lines the doubled string is then executed, so this is not a display artifact — it changes what runs.

Reproduced 7 times out of 7 in a single session (100%). Every affected input was a paste; every message typed by hand in the same session was unaffected.

Environment

• Claude Code 2.1.220 (latest at time of report, autoUpdatesChannel: latest)
• macOS 15 (Darwin 25.5.0), arm64
• "tui": "fullscreen" in ~/.claude/settings.json ← the only non-default input-related setting
• Shell: zsh; pbcopy present
• No custom keybindings (~/.claude/keybindings.json absent)
• Hooks configured: one UserPromptSubmit hook that only emits a <system-time> block and never touches the prompt (verified — it is a cat <<EOF of date output)

Evidence

Extracted from the session transcript (~/.claude/projects/<project>/<session>.jsonl), checking whether each <bash-input> payload equals its own first half repeated:

7 bash-input entries

[1] 2026-07-30T18:30:53Z v2.1.220 len=426 exact-half-dup=True
[2] 2026-07-30T18:32:53Z v2.1.220 len=58  exact-half-dup=True
[3] 2026-07-30T18:38:48Z v2.1.220 len=586 exact-half-dup=True
[4] 2026-07-30T18:40:11Z v2.1.220 len=590 exact-half-dup=True
[5] 2026-07-30T18:42:58Z v2.1.220 len=590 exact-half-dup=True
[6] 2026-07-30T18:43:42Z v2.1.220 len=196 exact-half-dup=True
[7] 2026-07-30T18:54:55Z v2.1.220 len=390 exact-half-dup=True

exact-half-dup is a strict inner[:len//2] == inner[len//2:] comparison. All seven are exact. There is no newline, space, or any delimiter at the join.

Why this is more than cosmetic

The concatenation happens at the join point with no separator, so the boundary silently corrupts the command:

Case 1 — a command truncated into a different, failing command.
Pasted:

cd /path/to/repo && git commit -m "msg" && git push

Executed: ... && git pushcd /path/to/repo && git commit -m "msg" && git push
Result: git: 'pushcd' is not a git command. The commit ran; the push silently did not. The repo was left committed-but-unpushed while the visible output looked like a normal error at the end.

Case 2 — a quoted payload corrupted mid-string.
Pasted a python3 -c "...print('added'))" one-liner. The join produced ...print('added'))python3 inside the quoted program text, yielding SyntaxError: invalid syntax. Harmless here only because Python parses before executing — the same join inside a shell string would have run.

Case 3 — accidentally benign.
rm -rf /tmp/aios-update-check doubled to rm -rf /tmp/aios-update-checkrm -rf /tmp/aios-update-check, which rm read as two targets: a nonexistent path (silently ignored) plus the intended one. It did the right thing by luck. A different path or flag combination would not be so forgiving — this is the shape of the bug that worries me most, because a destructive command can double into a valid destructive command with different arguments.

Workaround

Ending every pasted command with a space and # makes the doubling harmless — the second copy lands after a comment marker:

<command> #

becomes <command> #<command> #, which the shell executes once. This works only for single-line pastes; in a multi-line block only the final line is protected, and earlier lines of the second copy still execute.

Suspected area

"tui": "fullscreen" is the only non-default input-related setting present, which points at bracketed-paste handling in the alt-screen renderer — as though the paste payload is consumed from both the bracketed-paste buffer and the raw key stream. I have not been able to confirm this by bisection (it requires interactive typing to test), so treat it as a lead rather than a diagnosis.

Possibly a common duplicated-emit path with #74214 (fullscreen TUI emits the same OSC 52 clipboard write twice, byte-identical) and #41954. Those duplicate a clipboard write rather than concatenating content, and #74214 is Linux-without-pbcopy, so this is a different symptom — but "fullscreen renderer emits the same payload twice" is the shared shape, and they may have one root.

Expected

Pasted text is inserted once.