alfred-github-workflow: GitHub Search and Navigation from the Alfred Bar

What alfred-github-workflow solves, and for whom

The project is an Alfred workflow. Alfred is a macOS launcher; this workflow adds a `gh` keyword and a `ghe` keyword that open GitHub pages, search GitHub, and reach your own dashboard, issues, pull requests and notifications from the keyboard. The README describes it as a way to "search through GitHub (`gh`) and your GitHub Enterprise Cloud/self-hosted instance (`ghe`)".

That scope matters. This is a navigation and lookup layer for people who already use Alfred. It does not run GitHub Actions, it does not manage runners, and it does not replace `git` on the command line. The commands listed in the README are all page-openers or searches: `gh user/repo`, `gh user/repo issues`, `gh user/repo pulls`, `gh my notifications`, `gh s repo`. If your problem is "I want to jump to a pull request without opening a browser tab and typing a URL", this is the tool. If your problem is "I want to orchestrate a build", it is not.

How the gh and ghe keywords map to GitHub pages

The mechanism is keyword expansion inside Alfred. You type a keyword, a space, and an argument; the workflow parses the argument and produces a list of entries. Pressing `enter` opens the selected entry in the default browser, `cmd` + `c` copies its URL, `cmd` + `enter` pastes the URL into the frontmost app, and `shift` or `cmd` + `y` opens it in QuickLook.

The command grammar is regular enough to memorize. `gh user/repo` opens the repository, and a suffix selects a subpage: `#123` for an issue or pull request number, `@branch` for a branch, `*commit` for a commit, `/path/to/file` for a file, and words like `actions`, `admin`, `discussions`, `graphs`, `milestones`, `network`, `projects`, `pulse`, `releases` and `wiki` for the corresponding tabs. `gh @user` covers profiles, with `overview`, `repositories`, `stars` and `gists` as subpages. The `gh my` family covers your own account: `dashboard`, `notifications`, `profile`, `issues`, `pulls`, `repos`, `settings`, `stars`, `gists`, plus filtered variants such as `gh my issues assigned` and `gh my pulls review requested`. Search is separate: `gh s repo` and `gh s @user`.

Everything above is also available under `ghe` for an enterprise instance, which is the same command set pointed at a different host.

Installing PHP and logging in: a first run

The README states that the workflow requires PHP, which is no longer pre-installed since macOS 12 Monterey, and points to Homebrew. Install it first, because the workflow will not authenticate without it:

brew install php

Next, get the workflow itself. The README's only download pointer is the releases page, so the practical route is to open that page and install the latest `.alfredworkflow` file by double-clicking it. There is no package manager command in the README for this step.

Once installed, open Alfred and authenticate against github.com with the login command. The README says the login uses OAuth, so you do not enter credentials into the workflow:

gh > login

You should see Alfred's OAuth flow complete and the keyword become usable. After that, a first real query is a repository lookup:

gh gharlan/alfred-github-workflow

Alfred should list the repository entry; pressing `enter` opens it in your browser and `cmd` + `c` copies the URL. For an enterprise account the sequence is different: set the host with `ghe > url`, create a personal access token, then log in by pasting the token:

ghe > url https://github.mycompany.com
ghe > login <paste token here>

The README notes the token only needs access to your repos, and that under SAML SSO you must authorize it for the relevant organizations.

The PHP dependency is the sharpest edge

The README is explicit that PHP is no longer pre-installed on macOS 12 Monterey and later, and that Homebrew is the way to get it. That makes a Homebrew PHP installation a hard prerequisite for the workflow to function at all. If you cannot install Homebrew packages on a managed laptop, or if you deliberately keep a clean machine, this workflow is the wrong tool regardless of how well the command grammar fits your habits.

There is a second boundary in the README: private repositories inside organizations require that the organization approve the app. The README states that otherwise private repositories of that organization cannot be accessed, and links to a request page. That is a real gate, not a formality, and it is the kind of thing that surfaces after you have already installed everything and started typing `gh my repos`.

A third limitation is scope, and it is worth naming plainly. The workflow opens pages and runs searches. The README documents no command that creates a branch, pushes a commit, starts a workflow run, or reads run logs. `gh user/repo actions` opens the Actions tab in your browser; it does not control anything. If you came here expecting CI control from the launcher, the command list will disappoint you.

How it differs from the GitHub CLI

The obvious comparison is `gh` from GitHub, the command-line tool. The names collide, which is unfortunate, but the approaches differ in a way that decides the choice.

GitHub CLI is a terminal program that talks to the GitHub API and can create issues, open pull requests, run and inspect workflow runs, and script all of it. This workflow is an Alfred extension written in PHP that produces Alfred entries; selecting one opens a URL. Its output is a browser tab or a clipboard entry, not a machine-readable result you can pipe into another command. There is no documented way to script it, and the README documents no API surface of its own.

The trade-off is speed of access versus depth of action. If you want to open the pull request list for a repository while your hands are already on the keyboard and Alfred is your habit, the workflow is faster than typing a URL. If you want to do something to that pull request, the GitHub CLI is the tool that can. They coexist: nothing in the README suggests the workflow conflicts with an installed GitHub CLI.

Maintenance, releases and licence

The repository is not archived. The last push was on 2026-05-10, which is the same date as the v1.10 release. Before that, v1.9.2 landed on 2026-03-15 and v1.9.1 on 2024-12-05, so the release cadence is irregular rather than steady: roughly fifteen months between v1.9.1 and v1.9.2, then a short gap to v1.10. The README does not document a rollback path, and it does not describe a downgrade procedure, so the practical upgrade route is the release download plus the `gh > update` command listed under workflow commands, with `gh > activate autoupdate` and `gh > deactivate autoupdate` controlling whether updates arrive on their own.

The licence is MIT. In plain terms, that is a permissive licence: you can use, modify and redistribute the code, and the licence text in the repository is what governs. This is a description of the licence identifier, not legal advice, and anyone redistributing a modified build should read the LICENSE file rather than rely on this paragraph.

The dependency footprint is small. The repository's package.json declares a single dependency, `@primer/octicons`, used for the icons that appear in Alfred's result list. That means a broken or renamed icon package is a cosmetic problem, not a functional one, and it is the only JavaScript-side dependency the repository declares.

What to check before you commit to it

The README covers setup, key combinations and the full command list, but it is silent on several things you will want to know. It does not document how credentials are stored after `gh > login`, so if token storage matters to you, inspect the workflow's own files after installing rather than assuming. It does not document what `gh > delete cache` and `gh > delete database` remove, beyond the obvious implication of their names, which matters if you are troubleshooting stale results. It does not document rate-limit behaviour or what Alfred shows when GitHub returns an error.

There is also a structural detail worth knowing: the repository ships `composer.json`, `phpunit.dist.xml`, `phpstan.dist.neon` and `.php-cs-fixer.dist.php`, so it is a tested, statically analysed PHP codebase rather than a loose script bundle. If you intend to fork and modify it, that tooling is where you start. If you only intend to use it, the relevant files are the release artifact and the commands above.

Editorial conclusion

Adopt it if you already live in Alfred and want GitHub search, repo pages and notifications without leaving the launcher, and you are comfortable installing PHP via Homebrew on macOS 12 or later. Do not adopt it if you need CI pipeline control, if you cannot install PHP, or if your organization has not approved the OAuth app for private repositories. Verify first that `brew install php` succeeds on your machine, that `gh > login` completes the OAuth flow, and that any GitHub Enterprise instance answers at the URL you pass to `ghe > url`.

Frequently asked questions

Official sources

1. gharlan/alfred-github-workflow on GitHub
2. Issues
3. License: MIT
4. README
5. Releases