{"version":"2.1.239","anchor":"images-pulled-in-from-attachments-keep-their-on-disk-paths","canonical_anchor":"images-pulled-in-from-attachments-keep-their-on-disk-paths","heading":"Images pulled in from attachments keep their on-disk paths","tier":"notice","area":"Elsewhere","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.239\/e\/images-pulled-in-from-attachments-keep-their-on-disk-paths","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.239","markdown":"### Images pulled in from attachments keep their on-disk paths\n\nImages downloaded from attachments keep their file paths when a queued command is replayed.\n\n**What**\n\nWhen an attachment resolves to an image that Claude Code downloads and inlines, the file paths it wrote are now carried on the command and re-rendered if that command is replayed from the queue.\n\n**Details**\n\n- New field `inlinedImagePaths` on attachments and queued commands, and a matching message type `inlined_image_paths`.\n- The type is added to two attachment-type allowlists, so it passes the same filters as other attachment content.\n- Practical effect: a queued message that included an image still shows that image when it runs.\n\n**Evidence**\n\n`inlined_image_paths`\n\n- Area: Elsewhere\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 1\/5"}