Why a dragged attachment ends up in a temporary folder

When you drag an attachment out of a mail or chat window, the app does not hand over the file from your disk, because there is no file on your disk yet. It writes one on the spot, usually into a temporary directory, and hands over that. This is why a path you pulled from an attachment can start with /private/var/folders/ or sit deep inside a Library container, and why the file can be gone a day later.

What the path is telling you

Drag an attachment into a terminal window and you get text rather than the file. Read that text and you learn where the app actually put the thing. Three locations are common.

A path beginning /private/var/folders/ followed by two random-looking segments is your account’s temporary directory. The file in it is a real file, but macOS treats the contents as disposable and clears them on its own schedule and at restart.

A path inside ~/Library/Containers/ belongs to a sandboxed app’s private storage. Mail and chat apps keep downloaded attachments there so they can show a preview without asking for access to your folders. The file lasts as long as the app keeps it, usually until you delete the message.

A path in ~/Downloads or on the Desktop means the app wrote a normal file where you can find it. That is what you get when you drag an attachment to a Finder window rather than into another app.

Why apps do it this way

macOS has a feature called a file promise. When an app has something that could become a file but is not one yet, it can advertise the promise during a drag and only produce the bytes once it knows where they are going. A photo inside a library, a message attachment, a generated export: all of these are promises until the moment you drop.

Drop on a Finder window and the destination is a folder, so the app writes the file there and everything behaves as you expect. Drop somewhere that wants a path or plain text, such as a terminal, and there is no folder in the answer. The app still has to produce bytes, so it writes them where it can and hands over that location.

The same logic applies to a browser. Drag an image out of a web page into a terminal and you may get a temporary path, because the image existed in a cache rather than as a file you own. There is more on reading these strings in file paths on a Mac, explained simply.

Why it matters that the file is temporary

For a one-off look at a document, none of this is a problem. It becomes a problem in three specific situations.

You referenced the path in a script or a command you plan to run again. The path worked this morning and fails tonight, because the folder was cleared. The error will say no such file, which sends people hunting for a typo that does not exist.

You linked to it rather than copying it. A note or a document that points at a temporary path is pointing at something with no guarantee of survival.

You deleted the original message. Attachments held in an app’s container usually go with the message that carried them. The copy you thought you saved was never a copy.

The rule to remember: if you did not choose the folder, you do not own the file.

Getting a permanent copy, deliberately

There are three reliable ways to turn an attachment into a file that is really yours.

1. Use the app’s save command. Most mail and chat apps have a save or download action on the attachment itself. This writes to Downloads, or asks you where, and the result is a normal file.
2. Drag to a Finder window or the Desktop. Dropping on a folder makes the app fulfill the promise into that folder. This is the fastest route when you already have the right window open.
3. Copy the temporary file rather than referencing it. If you already have the path, copy the file somewhere you control before using it. In a terminal, cp the path to a project folder first and work from the copy.

Any of the three is fine. What fails is skipping the step because the file appeared to work once.

The staging step that fixes the sequence

The awkward part of the recommended route is the Finder window. To drag an attachment to a folder, you need that folder visible next to the mail window, which means arranging two windows before you can move one file. Most people skip it and drag straight into whatever they were doing, which is how the temporary path happens.

Ledge removes the arranging. Drag the attachment out of the message and up to the notch, or the top center of the screen on a Mac without a notch, and let go. The app fulfills the promise at that moment, so the file is written and it is on the shelf, out of the message and out of the app’s private container.

From there you send it where it belongs, with the destination window in front of you. Drag it into a Finder window and it lands in that folder as a normal file. Drag it into a terminal and you get a path that will still resolve tomorrow. Drag it onto a chat app you have set as a destination in Settings and it uploads. Files never leave the Mac in any of this; the shelf is a place to put something down, not a service.

If the attachment is destined for a project folder rather than another app, how to move a file from email to a project folder walks through that specific route.

Checking whether a path will last

When you are handed a path and want to know if it is durable, read the first two segments.

/Users/yourname/ followed by Documents, Desktop, Downloads or a folder you made is yours until you move it. /private/var/folders/ is temporary. ~/Library/Containers/ belongs to an app. /tmp leads into the same private area and is cleared on restart. A path on /Volumes/ is durable, but only while that disk is plugged in.

One habit is worth building: when a command works with a dragged path and you intend to run it again, copy the file into the project folder and point the command at the copy. Quote the path while you are there, which is covered in paths with spaces in the terminal, and how to avoid trouble.

Questions

Can I stop my Mac from clearing the private var folders directory?

No, and you should not want to. It is a scratch area the system manages for every app on the Mac. The fix is to copy anything you care about out of it rather than to keep it alive.

Is a file in an app’s container safe to link to?

Treat it as unsafe. It lives as long as the message or item that carried it, and it disappears when that is deleted or when the app cleans up. Save a copy somewhere you chose.

Why did the same drag give me a real file yesterday and a temporary one today?

Because the destination changed, not the source. Dropping on a folder makes the app write the file there. Dropping somewhere that only wants text makes it write the file wherever it can.