# RepoBar: a menu bar app that answers the question you open eleven browser tabs for > A native macOS app in Swift that keeps issue counts, CI state, releases, API quotas and local git status for many repositories in one menu, with a bundled CLI for the terminal. **steipete/RepoBar** — Show status of GitHub Repos right in your menu bar and terminal: CI, Issues, Pull Requests, Latest Release. - Repository: https://github.com/steipete/RepoBar - Website: https://repo.bar - Stars: 2,203 · Forks: 137 - Language: Swift - License: MIT - Published: 2026-10-08 · Updated: 2026-10-08 · Language: en - Canonical page: https://hysenlabs.com/projects/steipete-repobar ## One menu, per repository submenus The framing in the README's title is that this is GitHub without tab sprawl, and the feature list is specific about what fills the menu. The main menu shows issue and pull request pressure, stars, forks, recent activity, CI state, releases and contribution heatmaps, with filters for pinned repositories, local checkouts, or repositories with active work. Selecting a repository opens a submenu with recent activity and, when a local checkout is configured, its branch, upstream, dirty files, ahead and behind state, and worktrees. From there the app can open the checkout in Finder or a terminal, and can fast-forward clean repositories without discarding local changes. The restriction on that last one is deliberate and worth noting: fast-forwarding only happens when there is nothing local to lose. Setup is four steps and the README calls it the complete setup for GitHub.com. Open the app so its traffic light icon appears in the menu bar, sign in to GitHub through the browser, then choose visible, pinned and hidden repositories in Preferences, and finally select a repository to inspect. Local checkout status and archive backed offline data are explicitly optional. ```sh brew install --cask repobar ``` GitHub reports 2,197 stars, 138 forks and 4 open issues for the repository, with Swift as the language. ## A GitHub App token, with a PAT for the cases it cannot cover Authentication is the part of the README with the most careful wording, and it is where most GitHub tools get the tradeoff wrong. GitHub.com login uses a GitHub App user token, so access is limited by both the signed in user and the repositories where the RepoBar GitHub App is installed. Installing the app on an organization exposes that organization's private repositories. The limit follows directly from that design. If your private repositories sit outside the installation boundary, the app cannot see them, and that is a configuration problem rather than a bug. The README also notes that the repository picker keeps visibility rules visible when an account temporarily loses access, which is a deliberate choice to make permission problems diagnosable rather than mysterious. For the cases the App cannot reach, a Personal Access Token with repository and organization read access is available, and that is the route for SAML SSO organisations. GitHub Enterprise is supported through its configured HTTPS host and OAuth settings. Credential storage differs by build type, which is worth knowing before you file a bug. Release builds store credentials in the macOS Keychain. Debug builds use file backed storage specifically to avoid Keychain prompts during development, and `docs/auth-storage.md` documents the exact behaviour. ## Caching first, live lookups second, and an archive for when both fail This is the design decision that separates the app from a status page that stalls. RepoBar opens from its persistent SQLite cache first and refreshes GitHub data in the background, so the menu is readable immediately. A GitHub API Status menu shows REST and GraphQL quotas, endpoint cooldowns, and the age of cached samples, which means you can tell whether what you are reading is current. There is a third layer beyond live and cached. Git backed GitHub archive snapshots can seed the cache when GitHub is rate limited or unavailable, with RepoBar owning the imported database and archive configuration while leaving the source archive untouched. `docs/cache.md` covers the design. The optional clipboard reference monitor closes the loop on the original tab sprawl problem. It recognises GitHub URLs, issue and pull request references, commit hashes and workflow-run URLs, checks the cache first, and only performs a live lookup when needed. The recent releases are almost entirely about this layer rather than the UI. v0.9.3 keeps real REST and GraphQL usage visible when the quota endpoint incorrectly reports an entirely unused budget, preserves header counts and reset times until their window expires, and retains observed GraphQL quota across restarts without making extra requests. v0.9.2 stopped caching failed GraphQL responses. v0.9.1 added honouring GitHub secondary rate limits. Those are the kinds of fixes you only need if you have hit the problem. ## A CLI for the same data, which is how you would script it RepoBar bundles a `repobar` command for automation and diagnostics, installed from Preferences under Advanced, with `--plain` for terminal tables and `--json` for structured output: ```sh repobar repos --sort prs --plain repobar rate-limits --plain repobar cache status --json ``` That covers the three things you would want from a script: which repositories need attention, whether your API budget is about to run out, and whether the cache is telling the truth. `docs/cli.md` covers authentication, repositories, local git actions, caches, archives, settings and output formats. The repository layout explains how a Swift app ends up with a Node toolchain. `Sources/` and `Tests/` hold the Swift code, `RepoBariOS/` is the iOS target, `Config/` and `Resources/` hold configuration and assets, `ghql/` and `ghrest/` sit alongside a `GraphQL/` directory for the typed API layer, and `apollo-codegen.json` with `apollo-ios-cli` covers code generation. The Node side is driven by `package.json` with a pnpm workspace: scripts include `ghql` and `ghrest` run through tsx, plus tooling tests run under the Node test runner. Release automation includes an `appcast.xml`, a `.mac-release.env` and a `version.env`. ## Requirements that shift between your machine and CI There is a small inconsistency here worth naming, because it affects whether a first build works. The README's Development section asks for macOS, Xcode 26 with Swift 6.2, Node.js 22.13 or newer, and pnpm 11, then immediately says CI uses Node.js 26, checks the macOS targets with Xcode 26.1, and builds the iOS app and tests with Xcode 26.6 and its iOS 26.5 platform. Both can hold, and they do not conflict exactly: the local floor and the CI version are different numbers on purpose, with CI pinned ahead. But a first time contributor who installs Node 22.13 locally will be below what CI exercises, which is the kind of gap that produces a failure only in CI. The package manifest is the authority on the floors. `engines` requires Node `>=22.13.0`, `packageManager` pins `pnpm@11.27.1`, and the manifest is marked private, which is right for an application rather than a library. Supported application versions are stated as macOS 15 and iOS 26, and the README says plainly that RepoBar requires macOS 15 or newer. The three local scripts are minimal: ```sh pnpm install pnpm build pnpm check ``` `pnpm check` chains format, lint, test and the tooling tests, and `AGENTS.md` in the repository describes the layout and focused test commands. Two more version facts: the package version is 0.9.3 and the newest release tag is v0.9.3 from 2026-09-20, while the repository was last pushed on 2026-09-22, so the working tree is slightly ahead of the tagged build. ## Local projects and the one matching problem you have to solve Pointing the app at a projects folder is what enables the git half of the feature set. Preferences under Advanced holds that setting, and once set, RepoBar matches GitHub repositories to local checkouts and reports branches, worktrees, dirty files and upstream state. The matching is the interesting part, and `docs/reposync.md` is where the rules live: scanning, matching, sandbox access, caching and sync behaviour. Optional auto-sync is conservative by design, running only for clean, non-detached repositories that can fast-forward. Everything else is left alone. The macOS sandbox is the constraint that shapes those rules, and the fact that the app ships an entitlements file called `RepoBar.entitlements` says the boundary is handled deliberately rather than by disabling the sandbox. One last small thing: GitHub reports the homepage as `repo.bar` while the README badges link to `repobar.app`. Both resolve, so treat either as the canonical site and do not be surprised if a badge and the About window disagree. ## Conclusion RepoBar is worth installing if your work involves tracking more repositories than you can hold in your head, and the reason is the caching and quota handling rather than the dashboard. Opening from a persistent SQLite cache and refreshing in the background means the menu is usable when GitHub is slow or rate limited, and the API Status view tells you which state you are looking at. The authentication model is the decision to read first: a GitHub App user token limits you to repositories where the app is installed, with a Personal Access Token as the fallback for SAML SSO. Install from Homebrew, sign in, and set your projects folder before you judge whether the local git features are useful to you. ## FAQ ### How do I install RepoBar? Install the Homebrew cask with brew install --cask repobar. A signed app archive is also published on the latest GitHub release page. RepoBar requires macOS 15 or newer, and after installing you open it from Applications, sign in to GitHub, and pick your repositories in Preferences. ### Does RepoBar show private repositories? Yes, once the RepoBar GitHub App is installed on the organization that owns them, since GitHub.com login uses a GitHub App user token limited to repositories where that app is installed. For SAML SSO organisations or repositories outside the installation boundary, a Personal Access Token with repository and organization read access is the alternative. GitHub Enterprise is supported through its configured host and OAuth settings. ### Can RepoBar show local git status? Yes, once you set a projects folder under Preferences, Advanced, Local Projects. It then matches GitHub repositories to local checkouts and reports branch, upstream, dirty files, ahead and behind state, and worktrees, and it can open the checkout in Finder or a terminal. Optional auto-sync only fast-forwards clean, non-detached repositories. ### Does RepoBar have a command line interface? It bundles a repobar command installed from Preferences under Advanced, with a --plain flag for terminal tables and --json for structured output. Typical uses are repobar repos --sort prs --plain to list what needs attention, repobar rate-limits --plain, and repobar cache status --json to check the cache. The CLI reference in the docs covers authentication, repositories, git actions and archives. ## Sources - [License: MIT](https://github.com/steipete/RepoBar/blob/main/LICENSE) - [Project website](https://repo.bar) - [README](https://github.com/steipete/RepoBar/blob/main/README.md) - [Releases](https://github.com/steipete/RepoBar/releases) - [steipete/RepoBar on GitHub](https://github.com/steipete/RepoBar) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/steipete-repobar