Automate your Mac with launcher commands: shells, scripts, snippets

A launcher hotkey is a 50-millisecond window into anything your Mac can do. Most people use it to open apps. A small minority use it to run shell scripts, paste snippets, and automate the kind of multi-step tasks that would otherwise live in a Keyboard Maestro macro or a half-finished shortcut.

This post is for the people in that minority — or who want to be. It walks through every credible way to wire a launcher to your shell, your scripts, and your snippets in 2026, ranked by setup cost.

The four kinds of launcher automation

Before the how, the what. Launcher automation falls into four buckets:

One-shot shell commands — type a launcher trigger, run a command, see the output.
Scripts with arguments — type a launcher trigger plus a query, pass the query to a script, see the output.
Snippets / text expansion — type a short trigger, expand to a longer piece of text.
Chained actions — kill a process, open a Pull Request, switch a window, paste a result, in one shortcut.

Every launcher worth using in 2026 covers the first two. Snippets are a separate tool category. Chained actions live in the launcher's scripting layer and are where the time savings compound.

Shell commands as launcher actions

The simplest automation is "run this shell command from the launcher." Every launcher exposes it differently:

CmdSpace — built-in shell command runner; type >, then the command. CmdSpace returns stdout in the result list and lets you Enter to copy.
Raycast — extensions in the Script Commands category. Drop a .sh file in a folder, Raycast indexes it.
Alfred — Workflows with a "Run Script" object. Most flexible, requires the Powerpack.

The trick that elevates this from "novelty" to "daily driver" is wiring the launcher to pass a query into the script. A few examples that pay rent on my machine every week:

# kill-port.sh — kill whatever is on port $1
#!/usr/bin/env bash
lsof -t -i ":$1" | xargs -r kill -9

# new-branch.sh — create a git branch from a slug
#!/usr/bin/env bash
slug=$(echo "$1" | tr '[:upper:] ' '[:lower:]-' | tr -cd 'a-z0-9-')
cd "$REPO" && git checkout -b "feat/$slug"

# open-pr.sh — open the GitHub PR for the current branch
#!/usr/bin/env bash
cd "$REPO" && gh pr view --web 2>/dev/null || gh pr create --web

Each of these is 1-3 lines of bash and replaces 10-20 seconds of typing. The CmdSpace version is a script command with a port argument; the Raycast version is a Script Command with a query argument; the Alfred version is a Workflow with a Keyword input.

Snippets and text expansion

The second-most-used automation is snippets. You type ;sig and your email signature expands. You type ;date and today's date in ISO format lands at the cursor. You type ;addr and your shipping address fills the field.

In 2026, three reasonable snippet engines on macOS:

macOS Text Replacements (free, built-in) — System Settings → Keyboard → Text Replacements. Syncs across iCloud devices. Limited to plain text, no dynamic values.
Espanso (free, open source) — YAML-configured, scriptable, supports dynamic snippets that call shell commands or compute dates.
Raycast Snippets / Alfred Snippets — bundled with those launchers, decent UI, store snippets in the launcher's library.

The boring answer for 80% of users is macOS Text Replacements. It is free, syncs, and you already have it. The upgrade to Espanso is worth it once you want dynamic values like {{date:%Y-%m-%d}} or to insert today's standup message with the current branch name spliced in.

Snippets are the highest-ROI keyboard automation a non-developer can adopt. Snippets that save five seconds, used twenty times a day, save half an hour a week.

Chained actions: the launcher as a tiny scripting language

The deepest automation tier is chaining. Alfred has had this for a decade with Workflows: a graph of inputs, scripts, and outputs that lets you say "trigger keyword pr, run script that lists open PRs, let the user pick one, open the URL in browser." Raycast has equivalents as TypeScript extensions. CmdSpace exposes a JS API for the same shape.

A real example from my Workflows file: a "deploy" command that:

Asks for an environment (dropdown).
Confirms the current git branch is what I expect.
Runs pnpm build and tails the output in the launcher.
On success, runs the deploy script.
On finish, posts to Slack via webhook.

That whole chain is one keystroke, no cd to the right directory, no manual confirmation prompts. The first time I wired it together it took 40 minutes. It has saved hours since.

The threshold for this tier is roughly: "I do this multi-step task at least once a week and I would benefit from never thinking about the steps." Anything below that frequency, write a shell script and call it from the launcher.

Practical patterns that pay off

After several years of wiring launchers, the patterns that consistently earn their setup time are:

Kill by port. Replaces a 40-character lsof | xargs kill with kill 3000.
Open the README of the current repo in editor. Replaces a cd and a file path.
Push current branch and open PR. Replaces three commands.
Look up a customer by ID. A query passed to a curl command against your support tool's API, results in the launcher list.
Switch coffee shop Wi-Fi. A networksetup script that toggles between two networks.
Insert "test webhook" payload. A snippet with a randomized order ID.

Each of these is small. The point is not any single shortcut — the point is that ten of these wired up move 1-2 minutes a day of overhead from your hands to the launcher. That compounds.

What launcher automation is bad at

A short, honest list of where launcher automation breaks down:

Long-running tasks. If the script takes more than 5 seconds, you want a terminal, not a launcher overlay.
Tasks that need a GUI. Filling out a form is faster in the browser than scripting osascript.
Anything that requires confirmation dialogs. macOS permission prompts and launcher overlays do not interact well.
Cross-machine sync of complex workflows. Snippets sync (mostly). Workflows do not — you keep them in a dotfiles repo.

If you find yourself fighting one of these, step back to a real script or a Keyboard Maestro macro. The launcher is a 50-millisecond keyboard surface, not a job runner.

A starter pack

If you have not done launcher automation before, here is a 30-minute starter pack:

Pick a launcher that supports script commands (CmdSpace, Raycast, or Alfred with Powerpack).
Wire kill-port. Script takes a number, runs lsof -t -i :$1 | xargs kill. Use it once and you will never type the long form again.
Wire open-pr. Script runs gh pr view --web from the current repo path (set via env var). Press shortcut, GitHub opens to your PR.
Install Espanso. Migrate your top five Text Replacements to Espanso so you can add dynamic dates.
Add one snippet you use weekly. A meeting agenda template, a code review checklist, your standup format. Trigger it with ;sup or similar.

That is one half-hour, and you have built four small force-multipliers that fire every day.

Migrating from heavier tools

If you currently use Keyboard Maestro, BetterTouchTool, or Hammerspoon for automation, the launcher does not replace them — it complements them.

Keyboard Maestro is the right tool for cross-app automation that needs to drive the UI (click here, wait, type, click). Keep it for those.
BetterTouchTool owns trackpad gestures and global key remaps. Launcher does not compete.
Hammerspoon is a full Lua environment for power users. It overlaps with launcher Workflows but is harder to share.

The launcher's edge is keyboard ergonomics. If your hands are on the home row and you want to fire a shell command, the launcher wins on latency every time.

What this looks like at scale

After 18 months of consistent use, my own launcher has roughly 40 commands and 60 snippets wired in. Most of those I use weekly; a dozen I use daily. The aggregate time saved is hard to measure but tangibly real — the friction of "I need to do that thing, let me find the terminal" has been replaced with "press shortcut, type two characters, hit return."

You do not need 40 commands. You need three or four that fire often. The starter pack above is enough to get there, and the rest accrues naturally as you notice the next thing you do twenty times a week.

Try it on CmdSpace

CmdSpace ships with the most common dev commands wired in by default — kill-by-port, file search, clipboard history — and adding your own scripts is a matter of dropping a .sh file in a folder. No account, no cloud, local-first.