umputun / fya

86%

master: 86%

LAST BUILD ON BRANCH fix/multiline-bracketed-paste

branch: fix/multiline-bracketed-paste

CHANGE BRANCH

x

Reset

• fix/multiline-bracketed-paste
• dependabot/github_actions/actions/checkout-7
• feature/max-wpm-size-paste
• fix/bracketed-paste-injection
• fix/claude-tui-readiness
• fix/fya-turn-completion
• fix/gate-completion
• fix/stream-json-ralphex
• fix/strip-undeliverable-control-chars
• fix/transcript-select-prefix-match
• fix/transient-timeout-marker
• master
• no-activity-timeout
• refs/tags/v0.1.0
• refs/tags/v0.1.1
• refs/tags/v0.2.0
• refs/tags/v0.2.1
• refs/tags/v0.2.2
• refs/tags/v0.2.3
• refs/tags/v0.2.4
• refs/tags/v0.2.5
• refs/tags/v0.3.0
• refs/tags/v0.3.1
• refs/tags/v0.3.2
• refs/tags/v0.3.3
• refs/tags/v0.3.4
• refs/tags/v0.3.5
• resume-support
• structured-output-schema-envelope
• sync-subagents
• trim-stream-trailing-colons

fix: bracketed-paste all multi-line prompts, not just above-threshold

Multi-line prompts under the --max-wpm-size word threshold were still
typed rune-by-rune, emitting the fragile ESC+CR ("\x1b\r") for each
embedded newline. Claude's TUI intermittently reads ESC+CR as a submit,
fragmenting one prompt into many messages and hanging the turn until the
inactivity watchdog kills it — the exact failure the bracketed-paste
change was meant to retire, still reachable for shorter prompts.

Route any prompt containing a newline through bracketed paste regardless
of size. Single-line prompts still type rune-by-rune for human-like
pacing. Removes the now-unreachable ESC+CR newline path entirely.

Adds a regression test reproducing the production hang (a sub-threshold
multi-line rebase-conflict prompt) and updates the two tests that
asserted the old ESC+CR behavior.