{"version":"2.1.223","anchor":"remote-control-attachments-can-be-inlined-as-image-blocks","canonical_anchor":"remote-control-attachments-can-be-inlined-as-image-blocks","heading":"Remote-control attachments can be inlined as image blocks","tier":"soon","area":"Remote Control","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.223\/e\/remote-control-attachments-can-be-inlined-as-image-blocks","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.223","markdown":"### Remote-control attachments can be inlined as image blocks\n\nImages sent from remote control could be inlined instead of passed as file paths, but that is off.\n\n**What**\n\nImage attachments on bridge and remote-control messages can be downloaded and sent as content blocks instead of `@path` references, but the path is switched off in this build.\n\n**Details**\n\n- attachment resolution now returns `{ prefix, imageBlocks }` rather than a bare prefix string\n- gated on `tengu_bridge_inline_image_attachments`, whose in-source fallback is false, so absent a server value attachments keep using path references\n- when inlining fails it falls back to the path reference and reports telemetry `bridge_attachment_inline_image` with a `fallback_path_ref` variant\n\n**Evidence**\n\n`tengu_bridge_inline_image_attachments`\n\n- Flag `tengu_bridge_inline_image_attachments`: Not enough to say (read for one account on one subscription tier against v2.1.223; this account: no value returned, anonymous baseline: no value returned, compiled default: off) These values were read against a different version of Claude Code, so treat them as the nearest reading available instead of one taken on this release.\n- Area: Remote Control\n- Tier: Nothing to try yet\n- Useful: 2\/5\n- Signal: 3\/5\n- Present in the build but not switched on"}