I Nearly Froze Finder Trying to Copy a File Path

I turned a problem that should have taken ten seconds into an entire afternoon.

How it started: I only wanted to say one less thing

It began with something entirely ordinary.

Lately, I have often handed local files directly to AI for processing. The most troublesome part is not the task itself, but first telling the AI where the file is. If the path runs even slightly deep, I have to describe it one level at a time: Desktop, folder, subfolder.

That gave me an idea: could I add a “Copy File Path” item to Finder's context menu? One click would place the absolute path on the clipboard, ready to paste into an AI chat.

It sounded like a very small optimization—almost too small to be worth writing about.

But a great many problems begin with the judgment that something “should be easy.”

The process: the most dangerous state is “almost working”

I did not first ask whether the system already had a built-in solution. I went straight to the idea of building one myself: Automator, Finder services, workflows, writing to the clipboard, clearing the services cache, restarting Finder—one step after another.

At first, it even went quite smoothly. “Copy File Path” really did appear in the context menu.

The real problem emerged at precisely the stage when it “looked finished.” The menu was there, but it copied the wrong result. After one fix, it worked for some files but not others. Another fix broke files on the Desktop. More patching made Finder slow. Pushing further caused the context menu itself to start lagging.

What made it most frustrating was not complete failure, but an intermittent, half-working state.

It creates a powerful illusion: the problem seems to be within reach, with only one final step left. Yet this “almost there” state is exactly what draws people into endless rework. Fix one surface-level fault, and a deeper compatibility issue appears underneath.

Looking back, the whole episode was almost a textbook case: a tiny requirement, an extremely long path to fulfill it, and a complete mismatch between effort and return.

The real problem was not technical feasibility

What was worth recording was not why the Finder service was unstable, but something else:

I entered “custom tool” mode far too early for a problem that might already have had a ready-made answer.

This is a common and deceptively persuasive work habit. When a need is real and you roughly know the technical path, it is easy to confuse “I can build this” with “I should build this.”

Once that judgment takes hold, every additional hour begins to feel justified—you keep thinking you are already halfway done, so stopping now would be the greater waste.

That is why small problems can consume more time than large ones. Not because they are difficult, but because they look so much like something that will be “working any minute now.”

The ending: the system had the answer all along

By the time the real answer appeared, after all that tinkering, there was almost nothing to say.

macOS already has a native shortcut: `Command + Option + C` copies the full path of the selected file or folder in Finder. Hold Option while right-clicking, and “Copy as Pathname” also appears.

In other words, I had spent an afternoon trying to build a feature the system had already provided.

The embarrassing part was not that I could not write the script or find a technical approach. It was that, at the very beginning, I had failed to ask the most important question: Has the system already done this?

The solution: how to avoid doing this again

Reflection alone is not useful. Here are a few things you can take away directly.

1. Put this shortcut into muscle memory

No plug-in and no Automator workflow are needed. macOS supports it natively.

2. Ask AI to do one thing first: check whether a better solution already exists

The lesson was not limited to a macOS shortcut. It was a broader reminder: before asking AI to solve a problem, ask it to check whether the problem needs to be “solved” at all.

Now, whenever I am about to ask AI to build a tool, write a script, or optimize a workflow, I start with this:

Before you begin implementing anything, please first check:
1. Does the system already provide a native solution, or is there an existing off-the-shelf option?
2. If so, tell me directly. There is no need to build a custom solution.
3. If not, then start designing an approach.

It is a short prompt, but its purpose is to force both me and the AI to first ask whether the work is worth doing, instead of jumping straight into implementation.

3. Keep a small prompt library

Prompts that say “check before you begin” apply to many situations. Instead of improvising them each time, save them as templates and paste them when needed.

You do not need a complicated tool. An Obsidian note, a note-taking app, or even a plain-text file containing five to ten prompt templates you use regularly is enough.

The central idea is this: do not only ask AI to do things for you; ask it to help you identify the right question first.

In the end

If you look only at the result, this was simply a matter of discovering a shortcut for copying a file path.

But taken as a whole, the experience was a concrete reminder that many problems are not complicated. What is complicated is our reluctance to admit that the answer may be too simple.

So what stayed with me from this small episode was not the failed Finder service or the repeated rounds of workflow changes, but a more basic thought:

Before you start optimizing, check whether you are reinventing something that already exists.