Why dragging a file into an SSH session gives the wrong path

When you drag a file into a Terminal window, macOS types that file’s path at the cursor. In a local shell, that is exactly what you want. Inside an SSH session, though, the text goes to the remote machine, and the remote machine has never heard of /Users/you/Desktop/report.pdf. The file has to travel first; the path on its own cannot bring it.

What actually happens when you drop the file

Terminal treats a dropped file as text. It inserts the full path, with spaces and awkward characters escaped, and it does this the same way whatever is running in the window.

In a local shell, that path points at a real file on your Mac and the command works. In an SSH session, your keystrokes, including the inserted path, are sent to a shell running on the other machine. That shell looks for the path on its own disk, does not find it, and replies with something like No such file or directory.

Nothing was uploaded. None of the file’s contents went anywhere. Only its name did.

A quick way to check where you are: look at the prompt, which usually includes the host name, or type hostname and press Return. If it prints the server’s name, anything you drop into this window is being sent to that server as text.

Send the file first with scp

scp copies files using the same connection details you already use for SSH, and it ships with macOS. The trick is to run it from a local shell on your Mac, not from inside the session.

1. Press Command-T in Terminal to open a new tab. It starts a local shell on your Mac.
2. Type scp followed by a space.
3. Drag the file from Finder into the window. Its local path lands after scp, escaped correctly.
4. Type a space, then the destination in the form user@server:path, for example deploy@example.com:~/uploads/.
5. Press Return, and enter your password or passphrase if asked.

The finished command looks like this:

scp /Users/you/Desktop/Quarterly\ report.pdf deploy@example.com:~/uploads/

Switch back to the SSH tab and the file is now in ~/uploads on the server, where commands running there can use it.

For a folder, add -r before the path: type scp -r, a space, and drag the folder in. To go the other way, from the server to your Mac, swap the two halves: scp deploy@example.com:~/logs/app.log ~/Downloads/.

Or use sftp, where dragging works as expected

sftp opens an interactive session just for moving files, and it is the one SSH-style prompt where dropping a Mac path is correct. Its put command takes a local path, so the path your drag produces is exactly what it wants.

1. In a local tab, run sftp deploy@example.com.
2. Use cd to move to the remote folder you want. If you need to change the local folder too, lcd does that.
3. Type put and a space, then drag the file into the window.
4. Press Return. The file uploads into the current remote folder.
5. Use get with a file name to bring a file back to the local folder, and exit to end the session.

If you move files back and forth throughout the day, keeping an sftp tab open beside your SSH tab is often calmer than rebuilding scp commands each time.

Paths that trip people up

• Spaces on the remote side. Your drag escapes spaces in the local path, but the remote path you type by hand is up to you. Quote it, or keep spaces out of server folder names altogether. Paths with spaces in the terminal, and how to avoid trouble covers the local side in detail.
• The tilde. In the destination, ~ means your home folder on the server, not on the Mac. That is usually what you want.
• The trailing slash. Ending a destination with / makes it clear you mean a folder. Without it, if no folder of that name exists, scp writes a file with that name instead.
• The wrong tab. Running scp inside the SSH session copies from the server’s point of view, where your Mac path means nothing. If scp says a local file does not exist when you can plainly see it, run hostname first.

Keeping the files you are about to send in reach

Uploads rarely come one at a time. A config file from one folder, a build from another, a screenshot for the ticket. Finding each one in Finder while switching between terminal tabs is where the minutes go.

Ledge gives you a shelf at the top of the screen for this. Drag each file up to the notch at the top of a MacBook screen as you find it and let go, and it waits on the shelf. On a Mac without a notch, the shelf sits at the top center of the screen. When you are building the command, open the shelf with Option-Space and drop an item on the terminal. A terminal receives the path as text, the same thing a Finder drag produces, so typing scp and a space, then dropping from the shelf, gives you a correct local path. Auto-pasting into the terminal uses the macOS Accessibility permission, which Ledge asks for the first time you need it, never at launch.

Be clear about the limit. Ledge contains no networking at all: its release build is blocked from shipping if it so much as links a networking symbol. It never sends a file to a server. It gets the right path to the right place, and scp or sftp still does the transfer. For more on dropping paths into a local shell, see paste a file path into a terminal the easy way.

Questions

Can I drag a file from Finder straight onto a server?

Not through Terminal. A drag into a terminal only ever produces text. You need a transfer command such as scp or sftp, or some file-sharing method already set up on the server.

Why does scp say my file does not exist when I can see it?

Usually because the command ran inside the SSH session, on the server, rather than on your Mac. Run hostname. If it names the server, open a local tab with Command-T and run the command there.

Does dragging into Terminal work with folders too?

Yes. It inserts the folder’s path. For scp, add -r so the folder and everything inside it are copied.

Is the path Terminal inserts safe to use as it is?

For local commands, yes: spaces and special characters are escaped with backslashes. Glance at it anyway when a name contains quotes or unusual symbols. File paths on a Mac, explained simply covers how the path is built.