# Open in Code: a Finder toolbar button for Visual Studio Code

> Open in Code is a small native macOS utility that puts a button in the Finder toolbar so the folder you are looking at opens in Visual Studio Code in one click, using the current selection when there is one and the front window when there is not. It needs macOS 12 or newer, falls back to VS Code Insiders, and asks for Finder automation permission on first use.

**sozercan/OpenInCode** — 📂 macOS Finder toolbar app to open current folder in Visual Studio Code

- Repository: https://github.com/sozercan/OpenInCode
- Stars: 918 · Forks: 54
- Language: Swift
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/sozercan-openincode

## A toolbar button that answers one specific question

Open in Code does one thing: it takes the folder you are looking at in Finder and opens it in Visual Studio Code.

The problem it solves is small and specific. You are browsing a directory in Finder, you decide that directory is where you want to work, and the usual route is to open a terminal, change directory, and run the code command with the current path. Or you open VS Code and use its open folder dialog and navigate again. Both are two extra steps and a bit of retyping.

The project describes itself as a small, native macOS utility built for the Finder toolbar, and the goal is to get from the file you are looking at to the matching VS Code workspace without opening a terminal or navigating to the folder again.

What makes it native rather than a shell script is that it lives in the Finder toolbar itself. The table in the project description makes three promises: one click because the button lives in the Finder toolbar, Finder-aware because it uses your selection when available and the current Finder window when it is not, and stable or insiders because it prefers Visual Studio Code and falls back to Visual Studio Code Insiders.

That last point handles a real annoyance for anyone who runs the Insiders build on a work machine. The app does not ask you to configure which editor to launch.

## What actually opens, depending on what is selected

The behaviour is a lookup table, and the mapping is worth reading because it covers the cases people disagree about.

If a folder is selected, that folder opens. If a file or a Finder package is selected, its containing folder opens rather than the file itself, which matches how VS Code workspaces are structured and avoids the situation where you wanted the directory but got a single file. If multiple items are selected, the folder of the first selected item is used. If nothing is selected, the folder shown in the front Finder window is used.

That last row is the one that makes the app usable in the common case, which is scrolling a directory without selecting anything and then deciding to work in it. In that case there is no selection to work from, so the app falls back to the current directory of the window you are looking at.

The multi-item rule is the one place where the behaviour is a judgement call rather than an obvious answer. Opening the first selected item's folder is a deterministic rule, and it avoids the alternative of asking you which one you meant every time. The cost is that with a wide multi-selection across directories, the result depends on which item Finder reports first.

The fallback also explains why the Finder permission request exists at all. To know the front window's current folder when nothing is selected, the app has to ask Finder for that state.

## Installing the app and putting it in the toolbar

The requirements are macOS 12 or newer, and either Visual Studio Code or Visual Studio Code Insiders.

There are two install routes. The Homebrew route installs the cask.

```bash
brew install --cask sozercan/repo/open-in-code
```

The direct route is to download the app from GitHub Releases and move Open in Code.app to /Applications.

Neither route puts the button in the toolbar. That is a separate manual step, and it is deliberate, because macOS lets you add applications to the Finder toolbar by dragging them into it.

Open /Applications in Finder, hold the Command key and drag Open in Code onto the Finder toolbar, then drop it wherever you want the button to sit. Holding Command while dragging it again lets you reposition or remove it.

This design has a consequence worth naming. The button is not present until you put it there, and it is not present in other applications. Any script that opens files or folders in VS Code from a shell, a file manager or a launcher will not have this button, because the toolbar belongs to Finder specifically.

The app icon is described in the repository as living in a vscode.icon directory, and there are docs assets including the app icon and a hero image.

## The Automation permission and why it is unavoidable

On first use, macOS asks whether Open in Code may control Finder, and the instruction is to allow access so the app can read the current Finder selection.

This is the standard macOS privacy prompt for Automation, and it exists because the app queries Finder for the current selection and the front window's folder. There is no other way to answer the question the app was built to answer, so the prompt is a direct consequence of the feature rather than an overreach.

If access was previously denied, the recovery path is documented per macOS version. On macOS 13 or newer the setting lives in System Settings under Privacy and Security then Automation. On macOS 12 it is in System Preferences under Security and Privacy, then Privacy, then Automation. The entry to enable is Open in Code and the category is Finder.

The privacy model is worth understanding rather than just clicking through. The app needs read access to Finder state, and it uses that to decide which folder to hand to VS Code. What it does with that path is outside the scope of the prompt, but the repository carries an Open in Code.entitlements file, which is the place where such capabilities are declared, alongside an Info.plist and an English.lproj directory for the localised strings.

The project is written in Swift and built as a Swift package, with Package.swift at the repository root, Sources/ for the code, Tests/ for the tests, and scripts/ for the build and packaging helpers.

## What it deliberately does not do

This is a deliberately narrow utility, and the narrowness shows in three places.

It is macOS only. There is no Linux or Windows version, no browser extension and no cross platform CLI, and the project description says so plainly with the Made for macOS footer.

It is Finder only. The trigger is a Finder toolbar button, so the app is useful when you are already in a Finder window. If you arrive at a path from a terminal, from a search result, from a chat message or from an application that hands you a file path, there is no button to press.

It is VS Code only, with Insiders as a fallback. The table says it prefers Visual Studio Code and falls back to Visual Studio Code Insiders, and no other editor is mentioned. That is a defensible scope for a project by a VS Code user, but it means the app is not a general purpose open in editor utility.

Taken together, these limits mean the alternative you are replacing is not another application but a habit, namely typing code . in a terminal. If you already have that habit down to a single keystroke through a shell alias or a launcher, the savings shrink to the point where installing an extra app and granting an Automation permission may not be worth it.

## Releases, licence and the state of the project

The version history has one gap worth noticing. The releases are v2.0.0 on 2026-07-16 and v1.0 from 2018-04-28, with nothing in between. The repository is not archived, and the last push was on 2026-07-16, matching the v2.0.0 tag, so the current work is fresh.

A jump from 1.0 to 2.0 after that long a gap suggests the earlier version was a different thing and this release is the rewrite, or a substantial rearchitecture of it. The README presents a modern macOS app with a Finder toolbar item, an entitlements file and a Swift package, which is a plausible shape for a rewrite. What changed in the major bump is not spelled out in the README itself.

The licence is MIT, with the LICENSE file at the repository root and the badge confirming it. The README links a CONTRIBUTING.md for source builds, tests, packaging and release instructions, and an AGENTS.md is also present in the tree.

The repository also holds docs/ with the assets, and the GitHub Actions directory is present for the release and build workflows, since the Homebrew cask points at a tap that has to be updated when a new version ships.

The practical takeaway for a user is that this is a small, focused, actively maintained utility with a permissive licence and a very narrow job, and the question of whether to install it comes down to how much time you spend in Finder.

## Conclusion

Adopt Open in Code if you spend your day moving between Finder and Visual Studio Code on macOS and the repeated trip to a terminal to run code . is a friction you notice, because the app does exactly that one thing with no configuration and no menu bar clutter. Do not adopt it if you use Linux or Windows, if you want a shortcut that works outside Finder, or if you need to open other editors, since the app is deliberately limited to VS Code and its Insiders build. Verify first that you are on macOS 12 or newer with VS Code or VS Code Insiders installed, that you are willing to grant the Automation permission macOS asks for on first use, and that you drag the app into the Finder toolbar manually after installing, since nothing puts it there for you.

## FAQ

### How do I install Open in Code on macOS?

Use Homebrew with brew install --cask sozercan/repo/open-in-code, or download Open in Code.app from GitHub Releases and move it to /Applications. Either way you then have to drag it into the Finder toolbar yourself while holding the Command key.

### Which folder does Open in Code open in Visual Studio Code?

It depends on the Finder state. A selected folder opens itself, a selected file or Finder package opens its containing folder, multiple selections use the first selected item's folder, and with nothing selected it opens the folder shown in the front Finder window.

### Does Open in Code work with Visual Studio Code Insiders?

Yes. The app prefers Visual Studio Code and falls back to Visual Studio Code Insiders, so no configuration is needed if you run the Insiders build. The requirements are macOS 12 or newer plus either Visual Studio Code or Visual Studio Code Insiders.

### How do I fix Open in Code if macOS denies Finder access?

Enable Open in Code and then Finder in the Automation settings. On macOS 13 or newer that is System Settings, Privacy and Security, Automation, and on macOS 12 it is System Preferences, Security and Privacy, Privacy, Automation. macOS asks for this permission on first use.

## Sources

- [Issues](https://github.com/sozercan/OpenInCode/issues)
- [License: MIT](https://github.com/sozercan/OpenInCode/blob/master/LICENSE)
- [README](https://github.com/sozercan/OpenInCode/blob/master/README.md)
- [Releases](https://github.com/sozercan/OpenInCode/releases)
- [sozercan/OpenInCode on GitHub](https://github.com/sozercan/OpenInCode)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/sozercan-openincode