Mac file cut not working: the move Finder hides

A file is selected in Finder, ⌘X gets pressed out of habit, and nothing happens. The Edit menu confirms it: Cut is there, but it is dimmed. Every other application on the same Mac cuts text without complaint, so the natural conclusion is that something is broken, or that some setting has been turned off. Neither is true. Finder does have a move operation, it is bound to a different key, and it sits on the paste side of the transaction rather than the cut side. That single design decision explains most of the confusion, and it also explains the cases where the move genuinely does fail.

What follows is where the command actually lives, how dragging behaves differently depending on the destination, the specific conditions that dim the move even when the shortcut is correct, and how the same operation looks from a shell.

The clipboard holds a reference, not the file

Cutting text is safe because the text is small and the application owns it. The characters are removed from the document, held in memory, and put back somewhere else. If the paste never happens, the undo stack still has them.

A file is not like that. Cutting a 40 GB video would mean either copying 40 GB into the clipboard, which is absurd, or removing the file from its folder and leaving it in a state where nothing on disk points to it. If the paste never happens, because the app quits, the Mac loses power, or the clipboard gets overwritten by the next copy, the file is in limbo. Windows solves this by marking the file rather than removing it, and only performing the move at paste time, which is why a cut in Explorer can be abandoned harmlessly.

Finder reaches the same safety guarantee from the other direction. Nothing is ever pending on the source side. The clipboard receives a reference to the original file, exactly as it would for a copy, and the decision about whether the original survives is made at the moment of pasting. The result is that there is no cut, because there is nothing for a cut to do. There is only a copy, followed by a choice.

That is why the Cut item stays dimmed no matter what is selected in a Finder window. It is not a permissions problem and not a preference. The command has no meaning in this model.

The move is on the paste side

Select the file and press ⌘C. Then, at the destination, hold Option while opening the Edit menu. Paste Item changes into Move Item Here, and the shortcut shown beside it is ⌥⌘V. Apple documents it in the Mac keyboard shortcuts list:

Option-Command-V: Move the files in the Clipboard from their original location to the current location. Source: support.apple.com

The same substitution happens in the contextual menu. Right click in the destination folder, then press and hold Option, and Paste Item becomes Move Item Here while the menu is open. Releasing Option turns it back. This is the entire feature, and it has been present for many releases of macOS, which is why searches for a missing cut command turn up so little: the operation was never absent, only relabelled.

Two practical notes follow from the design. First, ⌘C on a file is not expensive, because nothing is duplicated until the paste. Copying a large folder to the clipboard and then deciding costs nothing. Second, the destination decides, so the same clipboard contents can be pasted as a copy in one window and moved in another. Nothing about the original selection changes in between.

Dragging is already a move, until the destination is a different disk

Most people never touch either shortcut, because dragging does the job. The rule that trips people up is that dragging changes meaning depending on the volume.

Within the same disk, a drag is a move. The file keeps its place on disk and only its directory entry changes, which is why it completes instantly regardless of size. Across disks, the same gesture becomes a copy, because the data genuinely has to be written to the other volume. Apple states the pair of behaviours plainly:

Copy files to a different disk: Drag the files to the disk. Move files to a different disk: Press and hold the Command key, then drag the files to the disk. Source: support.apple.com

External drives, disk images, network shares and iCloud Drive are all separate volumes for this purpose, so a drag into any of them copies by default. Holding Command turns it back into a move, which copies the data and then removes the original once the transfer verifies.

The mirror image also exists. Holding Option while dragging within the same disk forces a copy instead of a move, and holding Option together with Command creates an alias at the destination rather than moving anything. Three different results from the same drag, decided by modifier keys that are not visible until they are held.

Action	Same disk	Different disk
Drag	Moves	Copies
Command and drag	Moves	Moves
Option and drag	Copies	Copies
⌘C then ⌘V	Copies	Copies
⌘C then ⌥⌘V	Moves	Moves

Moving a batch, when the destination is nowhere near the source

The shortcut solves the single file case. Moving forty files into a folder three levels down on another drive is where the drag model starts to hurt, because both ends have to be visible at once.

The clipboard route scales without that constraint. Select the whole batch, ⌘C once, navigate anywhere at leisure, then ⌥⌘V. Nothing is pending on the source side while the navigation happens, so taking a detour through three folders to find the right destination costs nothing. This is the practical advantage of the paste side design over a real cut, and it is easy to miss while resenting the dimmed menu item.

For drag based work, two Finder features remove the need to see both ends. Dragging a selection onto a Finder tab switches that tab into view and drops there, so a tab can act as the destination while the source stays in the front window. Dragging onto an entry in the sidebar drops into that location directly, which makes the sidebar worth curating with the four or five destinations used every day.

Spring loaded folders cover the last case. Hold a dragged selection over a folder and the folder opens, letting the drag continue deeper without releasing. The behaviour and its delay are controlled in Finder settings under the general tab, and the delay is worth shortening if the wait feels long. The same happens over a sidebar entry and over a collapsed triangle in list view, so a drag can descend several levels in one gesture.

None of these change what the operation is. A drag between two locations on the same volume still moves, and a drag onto another volume still copies unless Command is held.

When Move Item Here is dimmed anyway

If Move Item Here appears but is greyed out, or the paste fails with an error, the shortcut is not the problem. The usual causes are specific and worth checking in order.

The item is locked. Get Info on the file shows a Locked checkbox. That checkbox sets the same immutable flag that a shell reports as uchg, and while it is set the file cannot be moved or renamed. A move attempt from a terminal returns Operation not permitted even when the account owns the file. Unlock it in Get Info, or clear the flag with chflags nouchg.

The destination is read only. A move needs write permission at the destination and delete permission at the source. Volumes mounted read only fail the first test, and this includes NTFS formatted drives, which macOS mounts without write support, mounted disk images built as read only, and system paths protected by System Integrity Protection.

The file is not fully downloaded. With iCloud Drive and Optimise Mac Storage enabled, an item shown with a cloud icon exists as a placeholder. Moving it out of iCloud Drive requires the data first, so the move waits on a download that may be slow or stalled.

Something has the file open. A file being written by another process can usually be renamed, but moving it across volumes copies and then deletes, and the delete step can fail while a handle is open. Quitting the owning application clears it.

The source is a search result or a tag view. Results shown in a Smart Folder or a tag listing are references. Some operations behave differently there than in the folder where the item actually lives, so it is worth navigating to the real location before deciding the command is broken.

The same operation from a terminal, and what it keeps

In a shell the distinction that Finder hides becomes explicit. mv renames within a volume and copies plus deletes across volumes. cp writes a new file. The difference shows up in the modification date, which matters when folders are later sorted or compared by date.

On a Mac running macOS 26, a file with a modification date set to January 2020 keeps that date after mv and after cp -p, but a plain cp stamps the copy with the current time. The original file's date is unchanged in every case. So a folder that suddenly shows every file as modified today has usually been copied without -p, not modified.

mv  old/report.pdf new/          # date kept, same volume is instant
cp -p old/report.pdf new/        # date kept, original stays
cp  old/report.pdf new/          # date becomes now
ditto old new                    # keeps extended attributes and tags

ditto is worth knowing about because ordinary copies can drop Finder tags and other extended attributes depending on the tool used. A file carrying a tag copied with ditto still reports that attribute at the destination.

Copying and then deleting is not the same as moving

Plenty of guides suggest working around the missing cut by copying, checking the destination, and then deleting the original. It reaches a similar end state, but three things differ.

The modification date is rewritten unless -p is used, as above. Extended attributes, including Finder tags and the colour labels built on them, may not survive depending on the copy method. And the window between the copy and the delete is a window in which two copies exist, which is exactly the state that later produces a duplicate hunt.

A real move avoids all three within a single volume, because nothing is written at all. Only the directory entry moves. Across volumes the copy is unavoidable, but ⌥⌘V and Command plus drag both hand the verify and delete steps to the system rather than to a human deciding by eye.

What to change first

Stop trying to make Cut work and bind the real command to muscle memory instead: ⌘C at the source, ⌥⌘V at the destination. If the moves are being driven from a shell anyway, the friction is usually not the shortcut but the switching between a folder window and a terminal that are looking at the same directory, which is what a file manager with a built in terminal removes, and what the comparison with other file managers lays out tool by tool. For a single window that keeps the folder view and the shell on the same path, Atriens is one option worth checking against the way the moves are actually done today.