nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Clone without attachments is still adding the attachments

mkurdi

Hello,

I would like to clone a Jira that has attachments but do not want to keep the attachments. So I clone without the attachments. However the new jira is created with the attachments.

The attachments show as non-editable and I cannot remove. How can I resolve this issue?

Note: The original jira had the attachments added as part of the comments.

Thanks!

Accepted answers

All comments

Dan Breyen

Hi @mkurdi welcome to the community. I found JRACLOUD-84939 and JRACLOUD-85201 on Atlassian's Jira Site. Either of which could be your issue. If you would agree, I would suggest voting for and watching it for updates. I voted for both of them. Looks like they both could use some help.

Hope that helps.

mkurdi

Thanks! Will do

HEMANT SAINI

Hi @mkurdi

This is expected behavior in Jira. When you use Clone and uncheck Include attachments, Jira only excludes attachments that are in the Attachments section of the issue.

If the files were added inside comments, Jira treats them as part of the comment content, not as attachments. So when you clone with Include comments checked, the comments get copied and the files inside them come along too. They show as non-editable because they are embedded in the comment history.

To clone without those files you have two options:

1. Clone with both Include attachments and Include comments unchecked
This creates a clean issue with only fields and description. You then manually copy any comments you still need, but without the embedded files.

2. Use Automation for Jira
Set up a manual rule with the Clone issue action. In the rule you can choose which fields to copy and explicitly skip Comments. That prevents any comment-embedded files from coming over. Then add back only the data you want.

Why you cannot remove them now:
Comment content is historical. Even as a Jira admin you cannot edit the attachment out of a cloned comment. You would have to delete the whole comment, which sometimes is not allowed by permissions.

For future tickets, ask users to add files to the Attachments section instead of dropping them into comments if you need to exclude them during cloning.

There is a suggestion ticket for this at jira.atlassian.com search for JRACLOUD-72695. Worth voting on it.

Hope that helps you clean up the process.

mkurdi

Thanks for feedback. Note that when I cloned I did not check any checkbox: Attachments, Links or Comments. But still ran into the issue

HEMANT SAINI

Hi @mkurdi

Thanks for the extra detail. If you did not check Attachments, Links, or Comments, but the files still showed up, there are two common reasons:

1. The files are embedded in the Description or another text field
Jira Clone treats inline images in the Description the same way it treats comment images. Even with all checkboxes off, the Description gets copied. If someone pasted a screenshot directly into the Description, that image comes with it. It will show under Attachments on the new issue but you cannot delete it because it is referenced in the field content.

Check this: Open the cloned issue, click Edit on the Description, and see if there is an exclamation mark image syntax like !image-2024-06-01.png|thumbnail! or a pasted image. If yes, that is the source. You would need to remove it from the Description to get rid of the attachment.

2. Known bug with Clone dialog defaults
There was a bug where the Clone screen showed all boxes unchecked, but the backend still included attachments if the original issue was created from an email or had certain system fields. Atlassian fixed most of this in late 2023, but it can still happen if your site has old feature flags. The workaround is to check the box, then uncheck it again before cloning. That forces the setting to actually apply.

How to clean the current cloned issue
Since you cannot delete the attachment directly, do this:
Step 1: Edit the Description and remove any inline image syntax or pasted images.
Step 2: Save. The unneeded attachment should disappear from the Attachments section after a minute.
If the image was in a custom text field, do the same for that field.

How to avoid it next time
Option 1: Use the Move action instead of Clone if you just need a copy in another project. Move does not bring over inline images unless you tell it to.
Option 2: Use Automation for Jira with a Clone issue action and explicitly set Description to a smart value that strips images. Example: {{issue.description.replace(!.*!,\s)}}
Option 3: Before cloning, edit the original and move any critical inline images to the real Attachments section. Then clone with Attachments unchecked.

If none of this matches your case, it might be worth raising a support ticket. Include the issue keys for both the original and the clone. Support can check the audit log to see exactly what the clone operation included.

Sorry you ran into this. The clone behavior with inline media is one of those Jira gotchas. Hope this helps you isolate it.

mkurdi

I applied the workaround on "How to clean the current cloned issue" and this resolved the concern. Thanks!

Evelin Bayer - codefortynine

Glad you found a solution, @mkurdi! 🙂

Disclosure: I work at codefortynine, the vendor of Deep Clone for Jira.

The manual workaround (editing the description to remove inline references, then deleting the attachments) works fine for a single ticket. But if you're cloning regularly or dealing with multiple issues, this approach doesn't scale well.

Jira's native cloning has well-known limitations — and the attachment behavior you ran into is one of them. If you're willing to use a Marketplace app for more advanced cloning, you might consider a professional cloning app such as our Deep Clone for Jira.

In Deep Clone, Description and Attachments are truly independent options. If you clone with the description but without attachments, the description text is copied but the embedded files are not physically added to the new issue. No surprise attachments, no manual cleanup needed.

If you also want to avoid broken links to removed attachments in the description, the built-in Field Editor lets you do search-and-replace during the clone — and you can save it all as a reusable Preset for future clones.

Best, 

Evelin Bayer | codefortynine

Clara Belin-Brosseau_Elevatic

Hi @mkurdi

As an alternative to the native cloning feature which can be limited in terms of granularity and flexibility, I can suggest trying our app Elements Copy & Sync.

You have the option to clone work items with or without the attachments:

Capture d’écran 2026-07-01 à 11.44.00.png

You can do the same with comments or any other field. You can check the documentation here.

I hope this helps

Dorota Popowska - Vilisoft

Hi @mkurdi

If you're looking for more control over what gets cloned, you might want to try Clone Expert for Jira.

During cloning, you can choose exactly what should be copied, including whether attachments should be included or not. This makes it easy to adjust the cloning behavior to your specific use case.

In addition, Clone Expert lets you control other cloning options and update specific fields before the new work items are created. It could be a good alternative if you need a more flexible cloning process.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-software

jira-cloud