Starboard: a macOS terminal that lives beside your Dock

The problem Starboard solves for macOS developers

Quake-style terminals are summoned and dismissed. You press a hotkey, a panel drops down, you run a command, you press the hotkey again, and the panel is gone. Starboard takes the opposite position. The README describes it as "a terminal that's just always there, not summoned, not dismissed." The panel sits beside the Dock, on screen, on every desktop, all the time. There is no hotkey to learn and no window to find, resize, or alt-tab back to.

The audience is narrow and specific. If you work on macOS, keep the Dock on the bottom edge, and your loop is "run one command in this project, then go straight back to the editor," Starboard removes the app switch from that loop. The README states the goal directly: run a command in whatever project you are in, then return to the editor without switching apps or losing your place. If you already keep a terminal window open on a second display and never lose it, the gain is smaller.

How the panel tracks the Dock and keeps shell state

The mechanism is a panel that reads the Dock's live on-screen position and repositions itself next to it. Accessibility permission exists for exactly that one purpose, according to the README, which also states the app makes no network requests and collects no data. Without the permission, Starboard still runs, but it is pinned to a fixed corner instead of hugging the Dock.

The shell is a real login shell, `zsh -l`, so `cd`, history, and state carry over between commands rather than resetting per invocation. That distinction matters: a one-shot command runner would force you to re-enter the directory every time. The panel never steals focus from the app you are in, and it stays visible on every Space, including over full-screen apps.

Two keyboard interactions are documented. Cmd+E expands the panel to full screen height and Cmd+E again snaps it back to Dock height. Cmd+T opens a theme picker, navigated with the arrow keys, applied with Enter, cancelled with Esc. The README lists 20 built-in themes, 10 dark and 10 light, including Gruvbox, Solarized, Monokai, One Dark, Tokyo Night, and Catppuccin.

Installing Starboard with Homebrew and clearing Gatekeeper

The README gives two install paths. Homebrew is the shorter one, but note that the tap lives inside the repository, so `brew tap` needs the full URL. The short form only works for repositories named `homebrew-*`, and the README adds that Starboard cannot go into the official `homebrew/cask` tap because that tap now requires notarized builds.

brew tap palamim/starboard https://github.com/palamim/starboard
brew install --cask palamim/starboard/starboard

Homebrew saves the download, the manual `mv`, and the updates, since `brew upgrade` picks up each new release. It does not skip the approval steps. The build is ad-hoc signed and not notarized, so the first launch is blocked outright with a "Starboard" Not Opened dialog. Click Done, then go to System Settings, Privacy & Security, and click Open Anyway next to the Starboard entry. Confirm Open Anyway again and enter your password. Starboard then launches and shows an Accessibility prompt; click Open System Settings and enable Starboard so it can track the Dock.

The manual path uses the same approval sequence and differs only in how the app gets to disk:

unzip Starboard.zip
mv Starboard.app /Applications/
open /Applications/Starboard.app

To launch it at login, the README points at System Settings, General, Login Items & Extensions, then the plus button and selecting Starboard.app. It states no script is needed for either install path. Building from source is a separate route: `swift build` followed by `.build/debug/Starboard` runs it once, while `scripts/install.sh` packages and code-signs a `.app` and registers it as a LaunchAgent. Logs go to `~/Library/Logs/Starboard.log`.

The Accessibility grant does not survive an in-place update

This is the failure mode to understand before you install. Updating in place, meaning overwriting the same `/Applications/Starboard.app`, which is also what `brew upgrade` does, needs a fresh Accessibility grant because each release is signed differently. The trap is that it may not visibly ask. System Settings can keep showing Starboard as already granted while it silently is not, and re-checking that same box does not fix it. The symptom is that Starboard stops tracking the Dock after an update.

The README gives two recovery paths: remove the Starboard entry from System Settings, Privacy & Security, Accessibility by selecting it and pressing the minus button, or run the reset command below, then relaunch Starboard to get a fresh prompt. The README refers to `CLAUDE.md` for the reasoning and for what to do if you also have a build-from-source copy installed via `scripts/install.sh`.

tccutil reset Accessibility com.starboard.app

The second limitation is display geometry. Starboard follows the Dock across displays, re-gluing itself within a second, and with an auto-hiding Dock it conceals and reveals along with it, except while you are actively typing or expanded. But only a bottom Dock is supported. A left or right Dock falls back to a fixed corner on the Dock's own screen. The README also lists a cosmetic known issue: pasted text briefly renders in the wrong color until the next keypress.

Starboard compared with Guake, Yakuake, and iTerm2 hotkey windows

The README names the alternatives itself: Guake, Yakuake, tilda, iTerm2's hotkey window, and Ghostty's quick terminal. The difference is not cosmetic. Those tools summon a terminal with a hotkey, hand it focus, and dismiss it when you are done. Starboard has no hotkey, never takes focus, and has no summon or dismiss cycle. The README's framing is that it sits there the way the Dock itself does.

That difference cuts both ways. A hotkey terminal gives you the full screen when you want it and nothing when you do not. Starboard occupies screen space permanently, next to the Dock, on every Space. If your Dock is on the bottom edge and you have horizontal room, that is a free panel. If you work on a small laptop display with the Dock auto-hiding, you are trading pixels for the absence of a keystroke. The comparison is really about whether the app switch or the screen space costs you more.

Maintenance, upgrade cost, and the MIT licence

The repository is not archived, and the last push was on 2026-09-10, the same day as the v0.20.0 release; v0.19.0 landed earlier that day and v0.18.0 on 2026-09-04. The release cadence is therefore dense, and `brew upgrade` is the documented update path, but every update carries the Accessibility re-grant cost described above. That is the real maintenance burden: not the install, but re-establishing Dock tracking after each signed release.

Starboard is MIT licensed, with the licence file at `LICENSE`. MIT permits use, modification, and redistribution with the copyright notice and permission notice retained. What MIT does not do is change the distribution situation the README describes: the app is ad-hoc signed and not notarized, which is why it cannot enter the official `homebrew/cask` tap. If your organization requires notarized software or manages Accessibility permissions centrally, that is a distribution constraint to resolve before deployment, not a licence question. Nothing here is legal advice; read `LICENSE` for the actual terms.

The codebase is small, which the README frames as a trust argument: just over 1,400 lines across 17 Swift files, with no network code. That is small enough to audit directly rather than relying on the project's own description.

Editorial conclusion

Starboard suits macOS 13+ users who want a persistent shell panel beside the Dock and are willing to click through Gatekeeper and grant Accessibility permission. It is the wrong tool if you want a hotkey-summoned terminal, a left or right Dock, or a notarized build you can hand to a managed fleet. Before adopting it, check that you can run `tccutil reset Accessibility com.starboard.app` if Dock tracking breaks after an update, and confirm your Dock is on the bottom edge.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. palamim/starboard on GitHub
4. README
5. Releases