[BUG] `!` bash-command stdout renders `&` as `&` in the transcript — corrupts copyable URLs

Environment

• Claude Code 2.1.224 (CLI, macOS — Darwin 25.6.0)

Bug

Stdout from a ! bang command is HTML-escaped when rendered in the transcript: every & displays as &. The child process's actual stdout is clean — the same command with stdout redirected to a file shows a literal &.

Repro

! printf 'https://example.com/?a=1&b=2\n'

Transcript shows:

https://example.com/?a=1&b=2

Redirecting the same command to a file and reading the file shows the correct https://example.com/?a=1&b=2.

Impact

Any URL printed for the user to open or copy is silently corrupted — every query parameter after the first is lost (&code_challenge=... reaches the server as a garbage amp;code_challenge parameter).

The common case is OAuth login flows: e.g. railway login auto-opens the browser (which works, since the CLI passes the clean string to the OS) but also prints the authorization URL as a copy-paste fallback. A user who copies the displayed URL — because auto-open failed, the wrong browser profile opened, or they're on a remote box — gets an opaque server-side rejection ("code_challenge_method must be provided"). We spent a month treating this as a vendor CLI bug (with a "never log in from inside Claude Code" workaround) before isolating it to the transcript rendering: the CLI's output was clean all along.

Expected

Bang-command output rendered verbatim, with no HTML entity escaping.