Using another app as Finder: what actually changes

There is no product called as-finder. The string turns up in searches from people who want a different application to do the Finder's job, and who are trying to find out whether that is a real option or a half measure. It is a fair question, and most of the answers online skip the part that decides it. The obstacle is rarely the features of the other app. It is the set of routes that lead into a file window, and how many of them can be pointed somewhere else.

What follows treats that as the actual problem. Which entry points are redirectable, what the open command can and cannot do, and which rules quietly change the moment the file window is not the Finder.

Six ways a folder gets opened, and where each one lands

Before installing anything, it helps to count how a file window appears during an ordinary day. The routes are not equal, and only some of them accept a different destination.

Route into a file window	Where it lands	Redirectable
Clicking the leftmost Dock icon	Finder	No, but the other app can sit next to it
Double clicking a folder	Finder	No
Reveal in Finder from a browser or editor	Finder	Only if that app offers its own setting
The Open and Save panel inside an app	A system panel, not a window	No
open . typed in a terminal	Whatever open -a names	Yes
A launcher or a global hotkey	Whatever the shortcut targets	Yes

Two of those six are fully under the user's control, and the rest are not. That ratio is the honest shape of the situation, and it explains why people who expect a clean swap come away disappointed while people who set up the two controllable routes report that the switch stuck.

The Open and Save panel deserves a separate note, because it is the route people forget when they estimate how much of the day is spent in the Finder. It is not a window belonging to any application. It is a system panel that draws its sidebar, its recents and its tag list from the Finder's configuration, and it appears inside every app that reads or writes a file. Time spent navigating there is time spent in the Finder's model of the disk regardless of which file manager is installed, which is one reason the sidebar in the Finder stays worth maintaining even after a switch.

The distinction that matters is between opening a folder and being handed a folder. Opening is initiated by the user, which is where a redirect can be inserted. Being handed a folder is initiated by another program, which decided years ago to call the Finder by name.

The open command is the redirect that works

The open command is the one place where the destination is a parameter rather than a fixed choice. Its own usage text lists the flags that matter here:

• -a opens with the specified application
• -b opens with the specified bundle identifier
• -R selects the item in the Finder instead of opening it
• -g runs without bringing the application to the foreground
• -n opens a new instance even when one is already running

A shell function built on -a turns every folder reference in a terminal into an entry point for the other app:

f() { open -a "Your File Manager" "${1:-.}"; }

Typing f opens the current directory there. Typing f ~/Projects/site opens that one. Because it is a shell function rather than a system setting, nothing about the Finder changes, and reverting means deleting one line.

Using -b with a bundle identifier instead of -a with a display name is worth the extra step for anything scripted. Display names change between versions and localisations, and a script that names an app in prose breaks quietly when the app is renamed. A bundle identifier does not.

The reverse direction is worth setting up at the same time. open -R reveals an item in the Finder from anywhere, which is the escape hatch for the few tasks that still need the system window, such as dragging into an application that only accepts drops from it.

There is a second redirect that does not involve typing at all. Holding Command while dragging an application onto a Finder window's toolbar pins it there, and dropping a folder onto that button hands the folder to the app. This covers the case the shell function does not: a folder already visible in a Finder window, reached by clicking rather than by path. Between the two, almost every folder that appears during a working day has a one action route into the other application.

Where scripts are involved, -g earns its place. An automation that opens a folder for later inspection has no business stealing focus from whatever is on screen, and without that flag every scripted open interrupts the current task. Adding it costs two characters and removes a category of annoyance that otherwise gets blamed on the app.

Naming rules belong to Finder, not to the disk

This is the change most people meet first and misread as a bug. The rules about what a filename may contain are enforced by the Finder, not by the file system underneath it, so they stop applying the moment something else is doing the writing.

A colon is the clearest case. The Finder refuses a colon in a name. The file system does not: creating a file called a:b.txt from a shell succeeds without a warning, and the file then exists with a colon in its name. A leading period behaves the same way. The Finder will not let one be typed, while a shell creates dotfiles all day.

The limit that does come from the file system is length. A single name component holds up to 255 bytes, and the unit is bytes rather than characters. Names written in Japanese, Korean or Chinese use roughly three bytes per character in UTF-8, so they reach the ceiling around a third of the way in compared with an ASCII name. A rename that fails on a long Japanese title and succeeds on the English one is not an inconsistency in the app.

The practical consequence is that a file manager which exposes the real name can create names the Finder will display oddly, and can also display names the Finder created but shows differently. Neither app is wrong. One of them is showing a presentation layer and the other is showing the bytes.

What other applications assume

Automation is where a partial switch shows up. A large amount of macOS scripting reads the Finder's current selection or the path of its frontmost window, because for two decades that was the only file window worth asking. Those scripts keep working, and they keep answering about the Finder, which may be showing a folder from last Tuesday while the real work is in a different app.

The same applies to the phrasing inside other applications. A browser download panel, a code editor, a screenshot tool and a chat client all offer some variant of showing the file in the Finder. A handful expose a setting for which application to use; most do not. Any workflow built on those buttons keeps routing back.

There are two ways to live with this. The first is to stop using those buttons and copy the path instead, then open it in the other app through the shell function above. The second is to accept the round trip and treat the Finder as a courier rather than a workspace: it receives the reveal, the item gets dragged or copied, and the actual work happens elsewhere.

Neither is elegant, and knowing that in advance is the point. A switch planned around the second option succeeds. A switch planned around the belief that the Finder will stop appearing does not.

Settings that stay behind, and metadata that travels

Not everything about a folder lives inside the folder, which changes what a new app can inherit.

Per folder view settings, including icon positions, window size and sort order, are written by the Finder into a hidden .DS_Store file in that folder. Another app is free to read or ignore it, and most maintain their own arrangement separately. The result is that the same folder can look sorted one way in one app and another way in the other, with no setting out of sync anywhere.

Tags behave differently, and better. A tag is stored as an extended attribute on the file itself, which is why it survives being copied to another volume that supports extended attributes and disappears on one that does not, such as a FAT formatted stick. Any application that reads extended attributes can see the same tags, so this part of the organisation does carry across.

The sidebar is a third case. The list of favourites is the Finder's own configuration, not a shared system list, so a replacement starts empty and has to be populated once. That is a ten minute job and worth doing deliberately rather than accumulating, since it is the rare chance to rebuild a list that has been growing by accident for years.

Aliases and symbolic links are the last thing to check. An alias created in the Finder keeps tracking its target when the target moves, and a symbolic link created in a shell points at a path and breaks when that path changes. Both look like a small arrow badge. A tool that resolves one but not the other will appear to fail on files that are demonstrably present.

Deciding in a week rather than an afternoon

The routes above are the thing to test, not the feature list. Set up the shell function, add the app to the Dock, and then spend a week noticing every time the Finder appears anyway. That count is the answer.

If the count drops to a handful of reveals from other apps, the switch is real and the remaining Finder appearances are a rounding error. If the count stays high, the friction is coming from somewhere the app cannot reach, and no amount of comparing feature tables will change it.

It is also worth being specific about what the switch is meant to fix. Wanting a second pane, wanting a real path bar, wanting the terminal in the same window and wanting an assistant that can see the current folder are four separate wishes, and they are answered by different tools. The feature list sets out what one window can cover, the comparison puts that next to the dual pane and transfer client categories, and the FAQ covers the questions that come up in the first week.

What to change first

Add the shell function and put the alternative in the Dock before changing anything else, then leave the Finder entirely alone for a week and count the times it still opens. Those two steps cost nothing and produce the only number that decides this. If most of the count is the terminal being in a different window from the folder, that specific gap is what Atriens was built to close.