{"version":"2.1.277","anchor":"new-pasted-content-field-on-userreplay-prompt-messages","canonical_anchor":"bridge-relayed-messages-can-now-carry-pasted-content","heading":"Pasted content is now tracked separately from typed text, including in bridge-relayed messages","tier":"internal","area":"SDK","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.277\/e\/new-pasted-content-field-on-userreplay-prompt-messages","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.277","markdown":"### Pasted content is now tracked separately from typed text, including in bridge-relayed messages\n\nUser messages, including ones relayed through the remote bridge, can now carry pasted text as a distinct pasted_content field\n\n**What**\n\n- User-message schemas, including the SDK's user-message-replay type, gain a `pasted_content` field: content the user pasted rather than typed, appended after the typed text (optionally wrapped in `<pasted_content>` tags). Image or document blocks still must go in `message.content`, not here. The internal user-turn extraction path now plumbs `pastedContent` through as well.\n\n- Inbound messages relayed through the remote-control bridge (excluding peer and slack-ping messages) now go through the same pasted-content merge used by the SDK, appending any attached pasted text blocks to the message body and emitting the existing `sdk_pasted_content` telemetry.\n\n**Why**\n\nKeeping pasted text separate from typed text lets Claude Code and the SDK tell the two apart, and extending this to bridge-relayed messages means the same distinction now applies consistently no matter how a message arrives.\n\n- Area: SDK\n- Names: `pasted_content`\n- Tier: Under the hood\n- Useful: 3\/5\n- Signal: 3\/5"}