A keyboard-only macOS terminal launcher workflow

If you spend your day in iTerm, Ghostty, or Terminal.app, the ergonomic gap between "I need a terminal" and "I am typing into one" matters more than for any other app. Three seconds of friction per terminal-open, ten times a day, is 30 seconds you could spend on the actual work. This post is the keyboard-only workflow I have refined over years of bouncing between launchers, terminal emulators, and shell configs.

If you skim: bind your terminal to a launcher hotkey, use a launcher with a terminal-focused command that opens a tab with a working directory pre-set, and skip the mouse entirely. The rest of this post is the specifics.

Why a launcher matters for terminal use specifically

Most "open a terminal" workflows assume you reach for the dock, click the icon, wait for the window. That works. It is also the slowest path. A launcher-driven workflow has three properties that compound:

1. Constant-time access. Cmd+Space → "t" → Enter is 4 keystrokes from any state.
2. Pre-set context. Good launchers can open a terminal at the directory of your current Finder window or of the current project.
3. No mouse required. Once you bind the hotkeys correctly, you can go from any app to a working shell without lifting your hand.

The launcher does not need to be specialized; any launcher with custom command support gets you 80% of the way.

The minimum viable setup

Three pieces:

1. A terminal emulator

In 2026, the credible options are:

• iTerm2 — mature, full-featured, the default recommendation. Cmd+T for new tab, Cmd+D for split.
• Ghostty — newer, GPU-accelerated, written in Zig. Fast and increasingly common.
• Apple Terminal — fine for casual use, less flexible.
• Warp — AI-augmented terminal, cloud-routed; skip if you want a local-only workflow.

For this post I will assume iTerm2 because it is the most common. Substitute as needed.

2. A launcher

Any launcher with custom commands works. The specifics differ:

• CmdSpace — built-in terminal here command that opens a new tab at the current Finder window's directory.
• Raycast — community extension for iTerm integration.
• Alfred — workflow that triggers osascript for iTerm.
• Spotlight — works for "open Terminal" but cannot pre-set directory or trigger advanced behaviors.

3. Shell config

Your .zshrc should have:

• A short alias for cd to your projects directory.
• A function for "open this project in editor + terminal."
• A small set of common shortcuts as aliases.

The hotkey chain

The workflow that has worked best for me:

Four launcher keys to open a terminal anywhere. From inside iTerm, the next four keys cover 95% of tab management.

The "terminal here" pattern

The most useful launcher command for terminal work is "open a new tab at the directory the user is currently looking at." Implementation depends on context:

• If you are in Finder, "here" means the front Finder window's path.
• If you are in an editor, "here" usually means the project root.
• If you are nowhere specific, "here" means your home directory.

For CmdSpace, the built-in terminal here command handles all three. For Raycast or Alfred, you write a small AppleScript or shell snippet:

tell application "Finder"
    set thePath to POSIX path of (target of front window as alias)
end tell
tell application "iTerm2"
    activate
    tell current window to create tab with default profile command "cd " & quoted form of thePath
end tell

Save as a workflow, bind to a launcher keyword like term or here.

This single command saves more time per day than any other launcher feature I use.

Project-scoped terminals

A more advanced version: launchers can open a terminal in a specific project directory by name. The pattern:

1. Launcher prompts for project name.
2. Match against a list of project directories.
3. Open iTerm at the matched path.

In zsh:

projterm() {
  local proj=$(ls ~/Projects | fzf)
  if [ -n "$proj" ]; then
    cd "$HOME/Projects/$proj"
    nvim .
  fi
}

But the launcher version is faster because it does not require an interactive fzf step. CmdSpace's project command takes the same approach with sub-25ms latency.

Common shell aliases worth adding

If you are setting up a keyboard-only workflow, these aliases pay for themselves quickly. Add to .zshrc:

# Navigation
alias ..="cd .."
alias ...="cd ../.."
alias p="cd ~/Projects"
alias dl="cd ~/Downloads"

# Git
alias gs="git status"
alias gd="git diff"
alias gco="git checkout"
alias gp="git pull"
alias gpsh="git push"
alias gl="git log --oneline -20"

# Quick edits
alias zshrc="$EDITOR ~/.zshrc"
alias source-zsh="source ~/.zshrc"

# Helpful
alias path='echo $PATH | tr ":" "\n"'
alias ports='lsof -i -P -n | grep LISTEN'

The ports alias alone has saved me hours. Combined with kill-by-port from your launcher (see kill a process by port on macOS), the dev-server workflow becomes trivial.

iTerm2 profile setup

A few iTerm2 settings that make keyboard-only work:

1. Use the system clipboard for selection. Profiles → Selection → "Applications in terminal may access clipboard."
2. Mouseless copy. Hold Cmd+Shift, use vim-style navigation to select, Cmd+C to copy.
3. Tmux integration. If you use tmux, iTerm's native integration replaces the tmux-in-iTerm window with iTerm tabs. Faster than nested tmux.
4. Profile per project. Different background colors per project context. Helps when you have 10 tabs open.

Ghostty users get most of these out of the box without configuration.

The "Cmd+Space everywhere" mental model

The bigger pattern this post fits into: every action on your Mac should be reachable from one root hotkey. Cmd+Space → keyword → Enter. The keyword can be:

• An app name to launch.
• A custom command (terminal, port kill, project open).
• A file path (jump to a specific document).
• A snippet (expand to text).
• A calculator expression.

A keyboard-only macOS workflow is, at its root, a launcher workflow with strong custom-command support. The keyboard-first Mac workflow day post covers a full day in this style; the Mac dev setup keyboard only post covers the broader environment.

When this workflow does not fit

For balance:

• GUI-heavy workflows (design, video editing, 3D) get less benefit from a launcher-driven terminal flow. Keep your launcher general-purpose, not terminal-specific.
• Pair programming sessions where someone else is driving can be confusing if you keep firing keyboard shortcuts they cannot follow.
• Beginner shells. If you are still learning zsh basics, a more deliberate "open Terminal, look at the prompt, think, type" rhythm helps build muscle memory. Speed comes later.

A typical day

For reference, my typical sequence as a developer using this workflow:

1. Cmd+Space → "p" → Enter → opens project list.
2. Type project name → opens iTerm at project root.
3. Cmd+T → new tab → npm run dev.
4. Cmd+T → new tab → start a watch task.
5. Cmd+Space → "code" → opens VS Code at the project.
6. Cmd+Space → "port 3000" → kills any leftover process.
7. Cmd+Space → "git status" → sees state. (Custom launcher command.)

Total time from "start working on project X" to "actually working": under 8 seconds. Without the launcher: maybe 30. Multiply by N project switches per day.

The bottom line

A keyboard-only terminal workflow on macOS in 2026 needs three things: a fast launcher, a terminal emulator with sane defaults, and a small set of zsh aliases. The launcher does most of the work. iTerm2 or Ghostty cover the terminal. Your .zshrc covers the rest.

For the broader picture, Mac dev setup keyboard only is the deep dive. For the launcher kill-by-port flow, kill a process by port on macOS. For automating with launcher commands, automate your Mac with launcher commands.

Sources

• Stack Overflow port-related questions — stackoverflow.com
• Zapier guide to Mac keyboard shortcuts — zapier.com
• Apple keyboard shortcuts reference — support.apple.com