gh-dash: A Terminal Dashboard for GitHub Pull Requests and Issues

The problem gh-dash solves for terminal-bound engineers

Reviewing pull requests usually means leaving the shell. You switch to a browser, find the right tab, read the diff, and come back. For anyone whose work is already terminal-shaped, that context switch is the cost. gh-dash targets exactly that gap: it renders a dashboard of GitHub pull requests and issues inside the terminal, as a gh CLI extension. The README's one-line pitch is that it is a rich terminal UI for GitHub that "doesn't break your flow".

The audience is narrow and specific. You need the GitHub CLI installed and authenticated, because gh-dash is distributed as an extension rather than a standalone binary you point at an API token. You need a terminal that handles TUI rendering well. In exchange you get pull request and issue data in a pane beside your editor, which is the workflow the topics list hints at: bubbletea, lipgloss, glamour, and the rest of the Charm stack.

What it is not matters as much. gh-dash is a viewer and a triage surface. It is not a replacement for git on the command line, and it does not manage local branches or commits.

How gh-dash renders GitHub data: GraphQL, YAML sections, and the Charm stack

The dependency list in go.mod tells most of the architecture story. gh-dash is a Go program built on charm.land/bubbletea/v2 for the event loop, charm.land/lipgloss/v2 for styling, charm.land/bubbles/v2 for reusable components, and charm.land/glamour/v2 for rendering Markdown. The GitHub side goes through github.com/cli/go-gh/v2 and github.com/shurcooL/githubv4, which means queries are GraphQL against the GitHub API, not REST calls assembled by hand.

Configuration is YAML. The repository root contains a .gh-dash.yml file, and the config stack is koanf with a YAML parser (github.com/knadh/koanf/parsers/yaml plus the file provider). That is the file a user edits to define which sections appear and what filters they run. The presence of go-playground/validator and go-sprout/sprout suggests the config is validated and supports templating functions, though the README excerpt does not document the schema.

Data flow is therefore: read .gh-dash.yml, turn each section into a GraphQL query, fetch through the authenticated gh session, and render the results as a list you can navigate. Notifications are handled by gen2brain/beeep and go-toast, which the dependency list includes for desktop alerts. The repository also ships a requests.http file and a .graphqlrc.json, which are development aids for exercising the API layer.

Installing gh-dash as a gh extension and running it the first time

The README does not print the install command itself. It links to the project's docs site at https://gh-dash.dev, and that link is the entry point the repository gives for setup instructions. The repository layout also shows a Taskfile.yaml and a devbox.json at the root, which are the build and development environment files for anyone compiling from source.

What the repository does show is how the project is packaged. The topics list on the repository includes gh-extension, and the module path is github.com/dlvhdr/gh-dash/v4. The README refers to the tool as DASH and links the release page under dlvhdr/gh-dash/releases. Everything about the packaging points at the GitHub CLI extension mechanism rather than a standalone binary distribution.

So the honest first step is to open https://gh-dash.dev and follow the install instructions there, because the README excerpt does not restate them. Once installed, the configuration file to look at is the example named .gh-dash.yml in the repository root. The README excerpt does not document that file's keys or its search path, so the docs site is the place to check before writing your own sections. The overview animation in the README shows the resulting dashboard, with pull requests and issues listed in panes.

Where gh-dash is the wrong tool

The clearest boundary is that gh-dash does not do Git. It shows pull requests and issues; it does not stage files, rebase branches, resolve conflicts, or push. If your problem is local version control, this is not the answer, and the related searches that compare it to lazygit are comparing two different categories of tool.

A second boundary is the host. Everything in the repository points at GitHub: the go-gh dependency, the githubv4 client, the gh extension packaging. The README does not mention GitLab or Bitbucket support, and there is no evidence in the dependency list of a provider abstraction. If your work lives on another forge, gh-dash cannot see it.

A third constraint is the authentication model. gh-dash borrows the gh CLI session, so it inherits whatever scopes and rate limits that session has. The README excerpt does not document token scopes or rate-limit handling, which means a large number of configured sections could run into API limits without an obvious in-app explanation. That is a design consequence of being an extension rather than a service with its own credentials.

gh-dash against lazygit: a dashboard versus a Git client

The most common comparison a reader will make is with lazygit, and the honest answer is that they overlap less than the search results suggest. lazygit is a terminal UI for Git itself: staging, committing, branching, rebasing, and interacting with the local repository and its remotes. gh-dash is a terminal UI for GitHub's review surface: pull requests and issues, fetched over GraphQL through the gh CLI.

Put differently, lazygit answers "what is happening in this repository" and gh-dash answers "what is waiting on me across these repositories". If you review code more than you write it, the second question is the one that costs you time.

The practical consequence is that running both is reasonable and not redundant. They occupy different parts of the workflow, and neither one substitutes for the other. Choosing between them only makes sense if you have decided which question you actually need answered.

Maintenance, licence, and the cost of upgrading

gh-dash is MIT licensed, with the licence text in LICENSE.txt at the repository root. MIT is permissive: you can use, modify, and redistribute the code, including in commercial settings. This is a description of the licence, not legal advice; read LICENSE.txt and your own organisation's policy if the distinction matters to you.

The repository is not archived, and the last push was on 2026-09-21, the same day as the v4.26.0 release. The release history shows v4.25.1 on 2026-07-08, v4.25.2 on 2026-07-10, and v4.26.0 on 2026-09-21, so the cadence over that window is a patch pair followed by a larger jump roughly two months later. The module path is github.com/dlvhdr/gh-dash/v4, which means major version 4 is the current line and a v5 would be a separate import path.

Upgrade cost is mostly the config. Because gh-dash reads .gh-dash.yml and validates it, a release that changes the schema can require edits to that file. The repository also carries .golangci.yml, .goreleaser.yaml, and Taskfile.yaml, so building from source is supported but is a Go toolchain exercise, not a one-line install. For most users the extension install path is the lower-maintenance choice.

Editorial conclusion

Adopt gh-dash if you already use the gh CLI and want pull requests and issues visible in a terminal pane without opening a browser. Skip it if you need Git operations, since gh-dash is a GitHub view rather than a Git client, and skip it for GitLab or Bitbucket, which the README does not cover. Before relying on it, check the repository layout for the config file name .gh-dash.yml, confirm the gh CLI is installed and authenticated, and read the docs site at gh-dash.dev for the current key bindings.

Frequently asked questions

Official sources

1. dlvhdr/gh-dash on GitHub
2. License: MIT
3. Project website
4. README
5. Releases