[BUG] Cross-session message sender renders fused to the prompt glyph (no separator before ❯)

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?

The inline cross-session message header that shipped in 2.1.228 (the change that closed #84831) renders the sender wrong, in two ways.

The sender is fused to the prompt glyph. Every incoming cross-session message paints the sender name hard against the ❯, with no separator:

@ Cross-session message display improvements❯ Render test for anthropics/claude-code#84831 ...

On a reply, the sender degrades to a raw socket basename. Same exchange, same terminal, two directions:

| direction | sender rendered as |
| --- | --- |
| A to B | @ Cross-session message display improvements (the session title) |
| B back to A | @ 19622 |

B's reply arrived as from="uds:/run/user/1000/cc-socks/19622.sock" with no from-name attribute, while A's original carried from-name="Cross-session message display improvements". So a session that replies by copying the from= attribute as its to, which is what the SendMessage tool documentation explicitly instructs, loses the name and the recipient sees a socket basename.

Both are the same element (the sender header) from the same release, so they are filed together. Happy to split them if you would rather track them separately.

Worth noting the evidence path: all of this is read straight out of the terminal's screen buffer with kitten @ get-text, so no clipboard or paste tooling is involved. I ruled out my own paste tooling first, since a reflow utility was in the loop and was the obvious suspect.

What Should Happen?

A separator between the sender and ❯, and from-name propagated on a reply so the sender stays legible in both directions. A number is not a sender, and the point of the 2.1.228 change was making the sender legible.

Error Messages/Logs

$ kitten @ get-text --extent all | sed -n '198,203p' | cat -A

<EOL>
@ 19622M-bM-^]M-/<EOL>
  Render report from the receiving side (v2.1.228):<EOL>
<EOL>
  I saw it fully inline, not collapsed. What arrived in my context was a block wrapped as <cross-session-message<EOL>
  from="uds:/run/user/1000/cc-socks/10604.sock" from-name="Cross-session message display improvements"<EOL>

# M-bM-^]M-/ is E2 9D AF, U+276F "❯". There is no 0x20 before it.
# The row ends right after the glyph; the body starts on the next row at indent 2.

Steps to Reproduce

1. Open two interactive sessions on one machine, A and B.
2. From A, discover B with ListAgents and send it anything with SendMessage.
3. Observe B's window: the sender and the ❯ are fused, e.g. @ <A's session title>❯ <body>.
4. From B, reply with SendMessage using the from= value it received as the to (as the tool docs instruct).
5. Observe A's window: the sender renders as a bare number, e.g. @ 19622.

To rule out paste tooling entirely, read both windows with kitten @ get-text rather than selecting and copying.

Claude Model

Opus

Is this a regression?

No, this never worked — the inline sender header is new in 2.1.228, so there is no earlier version where it rendered correctly.

Claude Code Version

2.1.228

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other (kitty)