Hoisted bash tool doesn't render \r\n correctly

[tenshiak]

Short description

only \n's are rendered in the bash tool, and that malforms the display output

What happened?

Regular pi's bash tool

aft's hoisted bash

This is a screenshot of the same tool call, just reloaded pi after enabling/disabling the hoisting in the configuration.

Bash output renderer mishandles Windows-style CRLF line endings (\r\n). It splits output on \n but leaves the trailing \r in each affected line, and the TUI interprets that carriage return during rendering, causing those lines to be visually overwritten or disappear. The captured tool output itself is still correct; only the displayed rendering is broken.

Pi also had this issue before, the fix was to normalize the display text newlines to \n: lmn451/pi-mono@c3aefbb

The exact command I told the agent to run: printf 'Exception:\nShouldly.ShouldAssertException: 1\r\n should be\r\n0\r\n but was not\n'

Diagnostics

Plugin version

0.51.2

AFT binary version

No response

Platform

Linux x64

Log output (optional)

[alfonso-aft]

Fixed on main (d087b9ea). Root cause: the hoisted bash pipeline preserved raw \r bytes in the rendered text — Pi's native bash normalizes line endings for display, so the same output diverged exactly as your screenshots show. The fix normalizes at the shared rendering layer (OpenCode's hoisted bash had the same defect and heals in the same change): \r\n becomes \n, and lone \r gets real overprint semantics — a progress bar that rewrote one line fifty times renders as its final state, the way a terminal would show it. Raw on-disk task artifacts stay byte-exact; only the rendered preview normalizes.

Ships in the next patch release — will confirm here when it's tagged.

[alfonso-aft]

Shipped in v0.51.3.