issue edit --body silently strips inline images from the description and deletes their attachments

[AmirL]

What happens

On Jira Cloud, editing an issue's description with jira issue edit KEY -b "..." (or via stdin, or the interactive editor) silently removes any images that were embedded inline in the description. Because the images' media/mediaSingle nodes are dropped from the new description, Jira Cloud treats the underlying attachments as orphaned and deletes them. No warning is shown, and Jira Cloud offers no restore, so this is unrecoverable data loss.

In my case the referenced attachment afterwards returned 404 and was gone permanently.

Version

jira version 1.7.0 (Homebrew), go1.25.5, darwin

Jira Cloud, description stored as ADF.

Steps to reproduce

1. In the Jira web editor, embed an image inline in an issue's description (this creates an ADF mediaSingle/media node backed by an attachment).
2. Run: jira issue edit KEY -b "New description text" --no-input
3. Open the issue in the browser.

Expected: the inline image is preserved, or at minimum a warning that inline media will be lost.

Actual: the description is replaced with plain text, the inline image is gone, and the attachment it referenced has been deleted from the issue.

The same loss happens with echo "..." | jira issue edit KEY --no-input, and via the interactive editor whenever the description text is changed.

Root cause

In internal/cmd/issue/edit/edit.go, the existing ADF description is translated to Markdown to seed the edit:

originalBody = adf.NewTranslator(adfBody, adf.NewJiraMarkdownTranslator()).Translate()

The ADF→Markdown translator has no representation for media/mediaSingle nodes, so inline images are dropped from originalBody before the user ever edits it. On save, the (image-less) body is converted back with md.ToJiraMD(body) and sent as the new description. The resulting ADF contains no media nodes, so Jira removes the now-orphaned attachments.

The "keep body as is if there were no changes" guard does not protect against this, because originalBody has already lost the images — any real edit produces a description without them.

Suggested directions

• Detect media/mediaSingle nodes in the existing description and either preserve them (merge them into the new ADF) or refuse the edit with a clear error unless an explicit --force / --allow-media-loss flag is passed.
• At minimum, print a prominent warning before overwriting a description that contains inline media, and document the behavior.

[hiSandog]

A warning alone is risky because noninteractive --no-input workflows could still destroy media. Until the ADF editor can preserve unsupported nodes structurally, the safe default is to refuse any body replacement when the existing document contains media/mediaSingle, with an explicit destructive override for callers that accept loss. Fixtures should cover multiple images, captions/links around media, unchanged edits, and ordinary attachments not embedded in the description so protection is neither partial nor overbroad.