Cross-session message bodies are HTML-escaped by Desktop and stamped `encoded="1"`, but the CLI never decodes — `&`, `<`, `>` arrive corrupted

Summary

Claude Desktop HTML-escapes the body of a cross-session message and stamps the envelope encoded="1", but the receiving CLI never decodes it. Any &, <, or > in a cross-session message arrives corrupted in the recipient's context.

One send reproduces it.

Environment

• Claude Code CLI 2.1.237
• Claude Desktop 1.34493.1 (MSIX/Store)
• Windows Server 2025 Datacenter (10.0.26100)

Reproduction

1. From session A, call mcp__ccd_session_mgmt__send_message targeting session B with a body containing bare &, <, >:

Token WEDGE-I6YKUG16UP. Echo this line back verbatim: a & b < c > d

1. Read B's transcript JSONL as bytes (do not judge from console output — a cp1252 console renders characters in ways that can manufacture or mask an apparent corruption).

Actual

The stored envelope contains the escaped entities literally:

Echo this line back verbatim: a & b < c > d

Byte-level confirmation via od -c of the stored payload:

0000000   v   e   r   b   a   t   i   m   :       a       &   a   m   p
0000020   ;       b       &   l   t   ;       c       &   g   t   ;
0000040   d  \n

The recipient answered the probe normally, so this is not a delivery failure — the message arrives, with the wrong bytes.

Expected

The recipient should see a & b < c > d, i.e. the text that was sent.

Mechanism

The Desktop side escapes the body and marks the envelope as encoded:

<cross-session-message from="local_<uuid>" name="…" encoded="1">

The encoded attribute appears to be advisory only: on the CLI side, body extraction strips the envelope with no decode step. Consequently the escaping is applied but never reversed.

Impact

Any cross-session message carrying code, shell snippets, comparisons, HTML, or URLs with query strings is silently mangled before the recipient reads it. In a coordinator/worker pattern this corrupts dispatched instructions with no error and no indication to either side — the sender sees success, the recipient sees plausible-looking but wrong text.

Suggested fix

Either drop the escaping (and the encoded="1" attribute), or teach the CLI to honour encoded="1" and decode before injecting the body.