A keyboard-only macOS dev setup that survives every Tahoe update

Every macOS update is a small earthquake for developer machines. Spotlight forgets your exclusions. Some shortcut you relied on stops working. A signed launcher you trusted needs a fresh permission grant. The setup you spent a weekend tuning in 2023 is mostly gone by the time Tahoe 26.2 rolls around.

This guide describes a keyboard-only macOS development setup that is deliberately boring, deliberately portable, and deliberately resistant to OS churn. It is the setup I rebuild on every new machine in under 30 minutes, with the explicit goal of surviving the next two annual updates without re-learning anything.

The constraints up front: no mouse for the inner loop, every tool installable via Homebrew or the App Store, configuration tracked in dotfiles, no proprietary cloud that holds your shortcuts hostage.

The four layers

A keyboard-only dev setup is four layers stacked on top of each other:

The launcher layer — what you press to open or do anything.
The terminal layer — where commands actually run.
The editor layer — where code lives.
The window layer — how those three share a screen.

If any layer requires a mouse for daily operation, the stack breaks. If any layer requires cloud sign-in to bootstrap, it is fragile. Build each layer once, copy the configs into a dotfiles repo, and the next migration takes minutes instead of days.

Layer 1: The launcher

The launcher is the single most-used app in a keyboard-only setup, more frequent than the terminal. It launches apps, runs scripts, manages clipboard history, kills processes by port, and opens files — without the trackpad.

Three reasonable choices in 2026:

CmdSpace — local-first, no account, kill-port and clipboard built in.
Raycast — well-documented extension store, requires an account for sync features.
Alfred — battle-tested, paid Powerpack for workflows, no recent major version.

For a setup that "survives every Tahoe update," the choice matters less than the discipline: pick one, configure ⌘Space (or ⌥Space if you keep Spotlight installed), and never look back. The shortcut is muscle memory; the launcher behind it is replaceable.

Three commands you should have wired to a single keystroke:

Clipboard history — ⌃⌥V or similar. Twenty-item history is enough.
Kill by port — type kill 3000, confirm, done.
Window snap — ⌃⌥←/→ to halves, ⌃⌥↩ to full.

If your launcher does not do all three, add a clipboard manager (Maccy is free) and a tiling tool (Rectangle is free). Both are open source and survive OS updates because they target stable APIs.

Layer 2: The terminal

A keyboard-only setup demands a terminal that opens fast, looks the same on every machine, and never asks you to sign in.

The recommendation in 2026 is straightforward:

Terminal app: Ghostty, Alacritty, or Apple's built-in Terminal.app. All three are fast, all three read config from a file, none requires a cloud account.
Shell: zsh (default) with a minimal .zshrc. Skip Oh My Zsh unless you actually use its themes — it is one more thing that drifts.
Prompt: Starship, configured via a single starship.toml you commit to dotfiles. Renders in milliseconds.

The keyboard-only test for the terminal: can you open a new window, split it vertically, and switch between splits without touching the trackpad? In Ghostty: ⌘N, ⌘D, ⌘⌥→. In tmux inside any terminal: ⌃B C, ⌃B %, ⌃B →. Both work; pick one.

Three terminal shortcuts every developer should have:

Open terminal here from launcher — most launchers ship a "new terminal in folder" command.
Jump words — ⌥← and ⌥→ in zsh, configured via bindkey.
Search history — ⌃R with fzf installed via brew install fzf and a one-line zshrc bind.

fzf deserves its own line. It is the single tool that makes a keyboard-only terminal worth using. Once ⌃R opens a fuzzy-searchable scrollback of every command you've run, you stop typing long commands twice.

Layer 3: The editor

The editor is where the keyboard-only constraint is least controversial. Every major editor today — VS Code, Cursor, Zed, Neovim, Helix — ships a command palette and keyboard navigation. The question is which one survives OS updates with the least friction.

A 2026 keyboard-only pick list:

Neovim — most portable, configured in Lua, runs in every terminal, immune to OS UI changes.
Zed — fast, signed, keyboard-driven, command palette is a first-class citizen.
VS Code — biggest extension ecosystem, command palette via ⌘⇧P, keyboard-friendly when you accept it.

Whichever you pick, the rule is the same: never click in the editor for an operation a shortcut can do. File switcher (⌘P in VS Code and Zed, :Telescope find_files in Neovim) replaces clicking in the sidebar. Command palette replaces every menu bar item. Multi-cursor and structural editing replace ten clicks of search-and-replace.

The dotfiles part: every editor on this list reads its config from a plaintext file. Commit it. When you migrate machines, git clone and your editor is the editor you used yesterday.

Layer 4: Windows

macOS window management is the layer Apple has improved most slowly. Tahoe's tiling is finally usable for casual users, but for a keyboard-only dev setup it is still slower than a dedicated tool.

Three options, ranked by how reliably they survive OS updates:

Rectangle (free, open source) — halves, quarters, thirds, all keyboard-mapped. Configured in .plist shippable via dotfiles. Survives every OS update I've tested since Big Sur.
Built-in macOS tiling (Tahoe 26+) — keyboard shortcuts are inconsistent across releases. Free, no install. Acceptable if you only need halves.
AeroSpace (free, open source, tiling WM) — i3-like on macOS. Higher learning curve. If you've used i3 or yabai before, you already know whether you want this.

The shortcut set I keep stable across machines: ⌃⌥← left half, ⌃⌥→ right half, ⌃⌥↩ maximize, ⌃⌥M next display. Four shortcuts. They live in Rectangle's config and survive everything.

Boot a fresh machine in 30 minutes

The whole point of "survives every Tahoe update" is reproducibility. Here is the sequence I run when I open a fresh Mac:

# 1. Homebrew
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

# 2. Core tools
brew install fzf ripgrep fd starship gh git neovim
brew install --cask ghostty rectangle visual-studio-code

# 3. Dotfiles
git clone git@github.com:you/dotfiles.git ~/.dotfiles
cd ~/.dotfiles && ./bootstrap.sh

# 4. Launcher
brew install --cask cmd-space   # or raycast / alfred

# 5. Sign in to nothing else

That is the whole setup. Five commands. Thirty minutes including downloads. No proprietary sync to wait on, no cloud handshakes that might fail behind a corporate proxy, no manual UI clicks except granting Accessibility permission to Rectangle and the launcher.

What breaks on a macOS update (and how to absorb it)

Every annual macOS update breaks something in this stack. Here are the recurring failure modes and the fixes:

Accessibility permissions reset — System Settings → Privacy & Security → Accessibility. Re-enable Rectangle and your launcher. Two checkboxes. Forty seconds.
Spotlight indexing exclusions disappear — re-add node_modules and your dev tree via the official method or mdutil -i off /Volumes/Dev. Or just stop relying on Spotlight (see Replace Spotlight for developers).
Default terminal changes color profile — pull your dotfiles, source .zshrc. Three seconds.
Launcher hotkey conflicts with new system gesture — open launcher preferences, remap. Thirty seconds. Document it in your dotfiles README.

The longest of these is rebuilding Spotlight exclusions, which is why my recommendation is to skip Spotlight for dev workflows entirely. A launcher with file search built in (CmdSpace, Raycast, Alfred) honors your exclusions persistently because the config lives in the launcher, not in macOS.

What I deliberately left out

This setup is opinionated by omission. Things that are not in it, and why:

App Store apps for core tools. They cannot be reinstalled by a script. Homebrew or signed downloads only.
iCloud-based syncing of preferences. Plist sync via iCloud is unreliable on first boot and locks you into Apple's account model.
Cloud-based clipboard history. Pasting your last copy from a cloud server is a privacy and latency tax for no real benefit.
AI-focused features that require sign-in. I will use AI tools that work offline (local Ollama, local Codeium). I will not bet my command palette on a remote endpoint.

The result is boring, fast, and portable. It does the same thing on a 2020 Intel Mac, a 2024 M3 Max, and tomorrow's M5 — because none of its pieces depend on hardware-specific drivers or cloud APIs.

The 30-day test

If you adopt a setup like this, give it 30 days before judging. The muscle memory for ⌃R history search, ⌘P file switcher, and your kill-port command takes about two weeks to internalize. After that, you stop noticing the keyboard at all — which is the goal. The fastest interface is the one you no longer think about.

When the next Tahoe update lands, you will spend ten minutes re-granting permissions and zero minutes relearning anything. That is what "survives every update" actually buys you.

Where to go next

Kill a process by port on macOS — the single most common port-3000 problem, ranked solutions.
A Mac terminal launcher workflow — how the launcher and terminal share the same keyboard muscle memory.
A day in a keyboard-first macOS workflow — what an actual workday looks like once these four layers are wired.

A keyboard-only setup is not a personality. It is a way to make your dev environment survive macOS's annual reshuffle without burning a weekend. Pick the tools above, commit the configs, and let the next update arrive without dread.