Triage and Workflow

Attaching files to a task

Updated 62 views

A report carries the evidence your users captured. A task often needs more: the design the page was supposed to match, a server log from the same minute, the spec that says which behaviour is correct.

Those files go on the task itself.

Three ways to attach a file

When you create the task. The create dialog has an Attach files button under the description. Files you pick there are on the task the moment it exists.

From the task afterwards. The task screen has the same button under its Attachments section — on the task's own page and in the board's side panel. Use it whenever a file turns up later, which is most of the time.

By dropping it on the screen. Drag a file from your desktop onto the open task and drop it anywhere. An outline appears while you drag to show the whole screen will take it. This is the fastest route for a screenshot you just took.

What the Attachments section shows

A task owns files from two places, and the list keeps them apart because they behave differently.

Attached files sit at the top. Hover one for a remove control and a download button.

Files from the description appear below, under From the description — the images you pasted into the description and any file chips it contains. They are the task's files too, and they are listed so nothing is hidden from you. They carry no remove control because removing them there would not stick: the description still references the file, so it would come straight back. Edit the description to take one out.

Each card shows the file name and size, and images show a thumbnail. Clicking a card opens the file.

Removing a file

Use the remove control on the card and confirm.

Removing a file detaches it from the task and deletes it from storage, provided nothing else references it — another task, a comment, or a report. When something else does, the file stays where it is and only this task stops pointing at it.

Anyone on the project can remove a task's files, not only the person who uploaded them. Attachments belong to the task, not to whoever happened to add them.

Dropping files into the description

Dropping a file inside the description editor while you are editing does something different: it puts the file into the text. Images appear inline, other files become a chip you can click.

That is usually what you want for a screenshot the description talks about, and it is why the drop zone leaves the editor alone. Drop on the editor to write with the file. Drop anywhere else on the screen to attach it.

Limits

A task holds up to 20 directly attached files. Images inside the description do not count towards that number, so a long illustrated description never uses up your attachment slots.

Everything else follows your plan: the per-file size cap, your total storage, and your total file count. See Plans, limits, and usage for the numbers on each plan. Attaching a file uses storage in the same way a report's screenshot does, and removing it gives the space back.

Reading attachments from Claude Code

The MCP server's get_task tool returns a task's attachments alongside its title, description, and counts. An agent working on a bug can see that you attached a spec or a server log, which is often the context that makes the difference between a plausible fix and the right one.

See also

  • Working with tasks and the board

  • Reading a bug report

  • Plans, limits, and usage

Was this article helpful?