Open terminal at folder on Mac, and land in the right place

Opening a terminal is trivial. Opening a terminal that is already sitting in the folder currently on screen is the part that keeps getting done by hand, usually by typing cd, then dragging a folder in, then pressing return. That works, and it is also the reason the same three seconds get spent forty times a day. macOS has documented routes for this that most people never switch on, and the routes have a detail worth knowing: they do not all produce the same working directory, and the directory you land in is not always the one the Finder window was showing.

What "at folder" means to the shell

A terminal window has one property that matters here: the working directory it starts in. Every relative path typed afterwards resolves against it, which means a command aimed at ./exports does something different depending on where the session began.

When Terminal is launched from the Dock or from Spotlight, the working directory is the home folder, because that is what a login shell inherits. Nothing about the frontmost Finder window enters into it. Opening a terminal "at a folder" means the shell is started with that folder as its working directory instead, so the very first command already applies to the right place.

The first thing to do after using any of the routes below is to confirm it worked, and there is exactly one reliable way:

pwd

That prints the working directory the shell believes it is in. It is worth building the habit, because the failure mode of these routes is silent. A session that opened in the home folder looks identical to a session that opened in a project folder until a command runs against the wrong tree. The cost of a wrong working directory is not a wasted keystroke, it is a command that succeeds in the wrong place.

The route Apple documents, and its two variants

The official route runs through the Finder path bar, which is off by default. Turning it on is a single menu item under View, called Show Path Bar. Apple describes the mechanism plainly:

You can use the path bar in a Finder window to open a new Terminal window or tab with the working directory set to a folder's location. Source: support.apple.com

With the path bar visible, hold Control and click any folder shown in it. Two entries matter. Choosing Open in Terminal starts a new Terminal window at that folder. Choosing Services and then New Terminal Tab at Folder adds a tab to the existing window instead.

The difference is not cosmetic. A new window every time produces a screen full of terminals that all look alike, and the one holding a long running process becomes hard to find. Tabs keep the count down but hide everything except the active one. Deciding which of the two is the default before adopting the habit avoids the usual outcome, which is fourteen open terminals by the end of a Thursday.

The other thing the path bar gives is precision about which folder is being handed over. Every ancestor of the current location appears in it, so opening a terminal two levels up is one Control-click rather than a navigation step followed by a second attempt.

Dragging the folder in, and what the shell receives

The manual route still deserves a place, because it is the only one that works when the target is not the folder being viewed. Apple documents dragging as a path entry mechanism rather than a launching mechanism:

Drag the file or folder to the Terminal window. The item's absolute path appears on the command line. You can also drag a folder from the title bar of a Finder window. Source: support.apple.com

The second sentence is the useful half. The small icon next to the folder name in a Finder window title bar is draggable, so the current location can be handed to a terminal without scrolling to find the folder inside its parent.

What arrives on the command line is an absolute path with spaces escaped, which is why typing cd, adding a space, and then dragging produces a command that runs correctly even for a folder named with spaces. The order matters: dragging first and typing cd afterwards leaves the command malformed, because the path lands wherever the cursor happens to be.

One route deserves to be retired. Copying a path out of the Get Info window and pasting it produces an unescaped string, so any space in it breaks the command silently by splitting one argument into several. Dragging never has that problem.

Laid side by side, the four routes differ in what they actually hand over, and picking between them is easier once that is explicit.

Route	What it produces	Best when
Path bar, Open in Terminal	A new window already in that folder	The folder is on screen and a fresh window is wanted
Path bar, Services, New Terminal Tab at Folder	A tab in the current window	Terminals are already open and the count is climbing
Drag folder into a terminal	An escaped absolute path as text	The session is already running and should stay running
Drag the title bar icon	The same, for the folder being viewed	The folder is open and scrolling to find it is wasted effort

The two path bar routes start a session. The two drag routes do not, which is the reason to keep both habits: a long running session with history and environment already loaded is worth more than a clean one, and dragging moves it without throwing it away.

Paths that arrive different from what was on screen

Several categories of folder produce a working directory that does not match what the Finder window displayed, and each has a distinct cause.

Symbolic links are the most common. Directories on macOS include several that are links to somewhere else, and a shell that follows one reports the link path while the real location is elsewhere. Running pwd in /tmp prints /tmp, while pwd -P prints /private/tmp, because the first is a symbolic link to the second. Scripts that compare paths as strings will disagree about which folder is in use.

Aliases are a different mechanism with a similar symptom. A Finder alias is not a symbolic link, and dragging one into a terminal hands over the path of the alias file rather than the path of its target.

Volumes are the second category. Anything on an external disk or a mounted network share lives under /Volumes, and the name in that path is the volume name at mount time. Plug in a second disk with the same name and macOS appends a number, so a path recorded last week can point somewhere else today.

iCloud Drive is the third and the most surprising. What Finder presents as iCloud Drive lives at ~/Library/Mobile Documents/com~apple~CloudDocs on disk. Commands run there behave normally, but the path is nothing like the one shown in the sidebar, and files that have been evicted to the cloud may need to download before a command can read them.

Which app answers when the menu item is chosen

The Services entries are published by applications, not by macOS, and the wording of each entry tells you which application will respond. Terminal registers two of them, labelled New Terminal at Folder and New Terminal Tab at Folder. It also registers entries for opening and searching man pages, which is why those appear in the same menu.

Third party terminals register their own. iTerm2 publishes entries labelled New iTerm2 Tab Here and New iTerm2 Window Here, which sit alongside Terminal's rather than replacing them. Both sets can be visible at once, and choosing the wrong one starts the session in an application that has none of your profile settings.

Every entry can be switched on or off, and given a keyboard shortcut, in System Settings under Keyboard, then Keyboard Shortcuts, then Services, in the Files and Folders group. The list there is long and most of it is irrelevant, which is why the entries that matter are worth finding once and assigning a key.

Whichever terminal answers, the shell it starts is the login shell for the account. Since macOS 10.15 that has been zsh for newly created accounts, so anything the session needs has to be in the zsh startup files rather than the bash ones. A session opened at a folder that stubbornly lacks a tool available elsewhere is almost always a session reading a different startup file than the one that was edited.

Permissions are the other thing that changes between the two applications. Folders such as Desktop, Documents and Downloads sit behind the macOS privacy controls, and the approval is granted to a specific application rather than to the account. A terminal that has been approved will list those folders normally, and a second terminal installed last week will report that the operation is not permitted on the identical path. The approval lives in System Settings under Privacy and Security, in Files and Folders and in Full Disk Access, and it has to be granted again for each terminal that gets adopted.

The moment the two windows stop agreeing

The routes above solve the first crossing perfectly and solve nothing after it. The shell starts in the right folder, then the first cd moves it, and from that point the Finder window and the terminal are pointed at different places while looking exactly as they did before.

This is where the time goes back in. A file created by a command has to be located again in Finder, and the Finder window is still showing the folder from ten minutes ago. Confirming what a command produced means either navigating the Finder window to catch up or running another command to list the directory, and neither is a decision anybody makes deliberately.

The count is the honest measure. A single crossing per task is cheap. A task that crosses six times, each crossing requiring a Control-click or a drag, is a task shaped by window management rather than by the work. At that point the useful question is not which shortcut to assign but whether the folder view and the shell should share a window, which is what a file manager with a built-in terminal is for, and what the comparison of the available options covers in detail.

What to change first

Turn on the path bar, then assign a keyboard shortcut to New Terminal Tab at Folder so the crossing costs one key instead of a menu. Run pwd the first few times to confirm the shell landed where the window was pointing. If the crossings keep multiplying after that, the fix is one window rather than a faster hop between two, which is the case Atriens is built for.