OpenInTerminal for macOS: a Finder toolbar app for terminals and editors

What OpenInTerminal solves for Finder users

The problem is path retyping. You are looking at a folder in Finder, you want a shell prompt in that folder, and the default route is to open a terminal and type cd plus the path, or drag the folder onto the terminal window. OpenInTerminal makes that a toolbar click. The README shows two core features: open items such as folders or files in a terminal or editor, and open the selected item in preferred apps such as GitHub Desktop or Fork.

The audience is macOS users who keep Finder in the loop. Developers who jump between a repository in Finder and a shell in iTerm, people who open a project folder in VS Code or Cursor from the Finder window, and anyone who wants a right-click path into a terminal. It is not a terminal emulator and not a shell. It is a launcher that reads the Finder selection and hands the path to another app.

Two products ship from the same repository. OpenInTerminal is the full app with GUI preferences, keyboard shortcuts, and context menu items. OpenInTerminal-Lite and OpenInEditor-Lite are stripped down. The README states the author personally prefers the Lite version because it is a one-click action while the full app takes two, and because it is lighter. That is a real design split, not marketing: the full app buys configurability with an extra interaction.

How the Finder extension and helper pass a path to your terminal

The repository layout shows the pieces. OpenInTerminalFinderExtension is the Finder Sync extension that contributes toolbar buttons and context menu entries. OpenInTerminalCore holds shared logic. OpenInTerminalHelper is a separate helper target. OpenInTerminal is the main app, and OpenInTerminal-Lite and OpenInEditor-Lite are their own targets. The project is built from OpenInTerminal.xcworkspace and OpenInTerminal.xcodeproj, and there are build-signed.sh and build-unsigned.sh scripts at the top level.

The data flow is: the Finder extension receives the current directory or the selected items, the app resolves which terminal or editor the user configured, and it launches that app with the path. Because Finder extensions run sandboxed and cannot simply spawn arbitrary processes, the helper exists to do the launch. That is a common macOS pattern, and it explains why the project is four targets rather than one.

The 2.3.9 release notes describe a security fix here: an AppleScript/command injection vulnerability that allowed arbitrary command execution through a crafted folder name when opening it in a non-default terminal or an editor. That tells you the mechanism is AppleScript-driven for at least some targets. Any tool that interpolates a filesystem path into a script string has this class of bug, and the fix landed in 2.3.9. If you are running an older build, that is the upgrade reason.

Install OpenInTerminal with Homebrew and open your first folder

The README gives one command for the cask. The same page states that signed builds are no longer provided for OpenInTerminal, OpenInTerminal-Lite, or OpenInEditor-Lite, and that you must either trust the unsigned binaries or sign them yourself. The Configuration document, Resources/README-Config.md, covers how to install and trust unsigned apps. Read that before you run anything, because the cask install is the easy half.

brew install --cask openinterminal

If you prefer not to use Homebrew, the README says to download the app manually from the releases page. There is no separate installer described.

After the app is trusted and running, the Finder extension has to be enabled in System Settings, and on macOS 15 and above the README is explicit that you must follow the Configuration document for the context menu items to appear at all. Once it is on, select a folder in Finder, use the toolbar button or the context menu, and pick your terminal. The 2.3.9 notes add that you can now place the Finder context menu items in a submenu, which keeps the top-level menu shorter.

The full app exposes preferences for choosing terminals and editors, and keyboard shortcuts. The 2.3.9 notes add an option to limit global keyboard shortcuts to Finder-only shortcuts, which matters if a shortcut was firing outside Finder. The Lite variants have no GUI preferences and no keyboard shortcuts, per the feature table, so configuration there is a different story.

Unsigned builds and the trust decision

This is the biggest practical friction. The README states plainly that signed builds are no longer provided for any of the three apps. On a modern macOS release, an unsigned app downloaded from the internet will be blocked until you either override the trust setting or sign it yourself. The project points at Resources/README-Config.md for that procedure, and the repository includes build-signed.sh alongside build-unsigned.sh, which suggests self-signing is an intended path rather than an accident.

That is a trade-off, not a defect you can wish away. A self-signed build is tied to your certificate and your machine, so every upgrade means rebuilding or re-trusting. If you manage Macs for a team, an unsigned Finder extension is a policy question before it is a convenience question. The alternative is to keep using the terminal's own working directory features and skip the extension entirely.

The 2.3.9 injection fix sharpens this. A Finder extension that turns a folder name into a command is a small attack surface, and the vulnerability was real enough that a security researcher reported it and the maintainer credited them in the release notes. Running 2.3.9 or later is the only version where that fix is present.

OpenInTerminal versus OpenInTerminal-Lite, and when neither is right

The README frames the choice directly: pick OpenInTerminal for GUI settings and extra features, pick OpenInTerminal-Lite if you just want to open a terminal quickly. The feature table backs this up. Both support the same long list of terminals (Terminal, iTerm, Hyper, Alacritty, kitty, Warp, WezTerm, Tabby, Ghostty, cmux) and the same long list of editors (TextEdit, Xcode, VS Code, VSCode Insiders, Atom, Sublime Text, VSCodium, BBEdit, TextMate, CotEditor, MacVim, the JetBrains family, Typora, Nova, Cursor, notepad--, neovim). Both support custom apps, with the README warning that not all apps support it. The differences are GUI preferences and keyboard shortcuts, which only the full app has.

Where this is the wrong tool: if you never use Finder, the extension is dead weight, and a shell function or the terminal's own directory option is simpler. If you need a signed, notarized binary for organizational reasons, this project does not ship one, and no amount of configuration changes that. If you only ever open one editor from one directory, a Finder Service or a small Automator action covers it without a Finder extension running in the background.

A real alternative in the same space is a Finder extension that focuses on the context menu rather than a toolbar, and the search data around this project includes RightMenu Master and FinderUtilities as names people look at alongside it. The difference in approach is scope: OpenInTerminal is specifically about routing a path into a terminal or editor, with an explicit terminal and editor support list, while a general Finder context menu tool adds arbitrary actions and treats opening a terminal as one entry among many. If your need is broader than terminals and editors, the general tool is the better fit; if it is exactly terminals and editors, the narrower tool has less to configure.

Maintenance, releases, and what the MIT licence lets you do

The last push to the repository was on 2026-07-14, and the most recent release, v2.3.9, is dated 2026-07-13. The previous full-app release, v2.3.8, was on 2025-01-07, so the gap between those two was about eighteen months. That pattern matters if you depend on prompt fixes: the project is not archived, but its release cadence is uneven, and a security fix sat in the 2.3.9 release rather than in a patch stream. The Lite line has its own version numbering, with v1.2.8 released the same day as v2.3.9.

The licence is MIT. In practical terms that permits use, modification, and redistribution, including in closed products, provided the copyright notice and permission notice are included. It does not give you a warranty, and it does not obligate the maintainer to fix anything. If you fork it to add a terminal the support list lacks, MIT lets you do that; you inherit the maintenance.

Upgrade cost is the unsigned-build tax described earlier. There is no described auto-update mechanism in the README. The documented paths are the Homebrew cask and manual download from releases, so upgrading means re-running the cask or replacing the app bundle, then dealing with trust again if macOS objects. Budget for that per release rather than assuming a silent update.

Editorial conclusion

Adopt OpenInTerminal if you work in Finder and want the current directory to land in iTerm, kitty, WezTerm, or an editor without retyping a path, and you accept that the build is unsigned and needs to be trusted or self-signed. Skip it if you live in the shell and never browse in Finder, or if you need a signed, notarized binary that installs without a Gatekeeper step. Before installing, read Resources/README-Config.md, because on macOS 15 and above the context menu items do not appear until you follow it, and check whether you want the full app or OpenInTerminal-Lite, which has no GUI preferences or keyboard shortcuts.

Frequently asked questions

Official sources

1. Issues
2. Ji4n1ng/OpenInTerminal on GitHub
3. License: MIT
4. README
5. Releases