GitHub app for Mac: three products share the name

Downloading a GitHub app for a Mac and finding that half the daily work still happens in a browser tab is the normal outcome, not a sign that the wrong thing was installed. Three separate products currently answer to that description, each covering a different slice of what people do on GitHub, and none of them covers the whole surface. Working out which slice matters is faster than trying each one in turn, and it changes what the browser is expected to do afterwards.

Three downloads, one description

The first is GitHub Desktop, a graphical client for Git. It handles repositories on the disk: cloning, branching, committing, stashing, reordering history, and pushing. It is the oldest of the three and the one most people mean.

The second is the GitHub Copilot app, which arrived much more recently and does a different job entirely. It is a desktop application for agent driven development, built to run several agent sessions in parallel and to carry work from an issue through to a merged pull request. The documentation lists macOS, Linux, and Windows as supported, and states that it is available on all Copilot plans.

The third is github.com itself, opened in a browser. This is not a download, which is exactly why it gets left out of comparisons, and it is where a large share of the actual work happens.

The three are not alternatives to each other. A developer can reasonably run all three in a week without any of them being redundant, because the boundaries between them follow the shape of the work rather than the shape of the product line.

Where GitHub Desktop's line sits

GitHub Desktop is about the copy of the repository on the disk. It shows changes to files, stages them, writes commits, moves branches, and syncs with the remote. It also reaches slightly past pure Git: pull request branches can be checked out from a list, and the status of checks on a branch can be viewed and re-run from inside the client.

The system requirement is short and worth confirming before downloading anything.

macOS 12.0 or later Source: docs.github.com

That floor rules out machines that stopped at Big Sur or earlier, which is a meaningful population of otherwise healthy Macs. For those machines the browser is the entire answer, and the rest of this decision collapses into one option.

What Desktop does not attempt is the conversational half of GitHub. Reading an issue thread, leaving a review comment on a specific line, reading the log of a failed workflow run, moving a card on a project board, or approving a deployment all happen elsewhere. That is a design choice rather than a gap: the client is built around the working copy, and the working copy does not contain any of those things.

The Copilot app solves a different problem

Confusing the two is easy because both are desktop applications with GitHub branding, and the newer one is described in language that sounds like it might replace the older.

The Copilot app is organised around agent sessions rather than around a working copy. Its stated purpose is directing AI agents across parallel workstreams, with issues, pull requests, branches, and CI connected natively so that work can be triaged, run, steered, and landed without moving between a terminal, an editor, and a browser. It is built on the Copilot command line tool underneath.

Two things follow from that. It is not a general GitHub client, so someone who wants to read a discussion thread or adjust repository settings will still leave it. And it is not a Git GUI in the Desktop sense, since its unit of work is a session on a branch rather than a diff waiting to be staged.

For a team already running agents, it consolidates a workflow that otherwise sprawls. For someone who wanted a window that shows GitHub, it is a much larger tool than the question called for.

The surface that never leaves the browser

Listing this honestly is what makes the decision easy, because it turns out to be most of the day for anyone not writing code full time.

The notifications inbox, issue threads, pull request review with inline comments, workflow run logs, project boards, discussions, releases, security alerts, gists, organisation and repository settings, billing, and Codespaces are all web surfaces. Some have partial representation in a client, and none are fully covered by one.

The pattern is consistent once seen. Anything that involves other people reading and replying stays on the web. Anything that touches files on the disk moves into a client. A reviewer, a maintainer triaging issues, or an engineering manager watching pipelines spends the majority of their GitHub time in the first category, which is why installing Desktop often changes less than expected.

That is not a criticism of the client. It is the reason the browser tab deserves as much setup attention as the applications do, since it is carrying more of the load than either of them.

Two accounts is where the trouble starts

A work account and a personal account on the same Mac is common, and the two halves handle it very differently.

GitHub Desktop keeps accounts in its settings. The Accounts pane offers one sign in for GitHub and a separate one for GitHub Enterprise, so a github.com account and an enterprise account coexist without argument. Two github.com accounts is the case that pane is not shaped for.

The browser has the opposite problem. One profile holds one github.com session, and signing in as the other account signs the first one out. Every workaround people reach for has a cost. Private windows lose the login on close. Signing out and back in several times a day invites two factor prompts and eventually a commit authored by the wrong identity. Neither is a stable arrangement.

Separate browser profiles fix the session properly, because cookies and login state are per profile. What they do not fix is finding the right window, since both look identical in the Dock and in the application switcher. Building one standalone window per account closes that last gap: each account gets its own icon, its own window, and its own isolated profile underneath. The Features page describes the isolation involved, which covers cookies, session, history, and cache.

The identity that ends up on the commit

Separating the browser windows solves who is reading. It does not solve who is writing, and that second half is where a two account setup usually leaks.

Git records an author name and an email address on every commit, taken from configuration rather than from whichever client is in front. GitHub Desktop asks for both during setup and keeps them in its settings, which means one pair of values becomes the default for everything committed through it. A work repository cloned later inherits that pair silently.

The result is a commit pushed to a company repository carrying a personal address, or the reverse. On the receiving side it is visible to everyone, it can fall outside a contributor agreement, and rewriting history to correct it is more disruptive than the original mistake. Nothing warns about it at the time, because as far as Git is concerned nothing went wrong.

The fix is per repository configuration rather than a habit of remembering. Setting the address inside each work repository overrides the global default for that repository only, and it survives every future clone of that same checkout. Checking one existing commit in each repository is a two minute audit that answers whether the problem is already present.

There is a second, quieter version of the same issue. Commit signing keys and personal access tokens are also account bound, so a setup that signs commits correctly for one identity will fail or sign wrongly for the other. Anyone running two accounts seriously ends up with two keys, and the same per repository configuration decides which one is used.

None of this is fixed by choosing a different application. It sits underneath all three of them, which is why it is worth settling before deciding which window goes where.

Comparing what each container covers

Task	GitHub Desktop	Copilot app	github.com in a window
Commit, branch, stash on disk	Yes	Session based	No
Check out a pull request branch	Yes	Yes	No
Review code with inline comments	No	Partly	Yes
Read and reply to issues	No	Yes, for agent work	Yes
Read a failed workflow log	Status only	Yes	Yes
Project boards and discussions	No	No	Yes
Two github.com accounts at once	No	No	Yes, one window each
Minimum macOS	12.0 or later	Supported on macOS	Whatever the browser needs

The last row is the one that decides things on older hardware. A browser that still receives updates outlives the published floor of most native clients, which is why a web surface in a proper window is the arrangement with the longest life on a machine that will not be replaced this year.

Setting up the window so it earns its place

A tab pinned since Monday is not the same thing as a window, and the difference shows up in three places.

Point the window at the surface actually used most, which for a reviewer is the notifications inbox and for a maintainer is often the issues list of a single repository. A window that opens on a useful page removes a navigation step from every single visit.

Sign in inside that window and let it hold the session, so that the account binding is decided once. This is the piece that makes two accounts workable, since each window is permanently one identity and there is no moment where the wrong one is current.

Keep extensions deliberate. A window built on an installed browser keeps them, which is useful for a password manager and for anything that improves code review, and the ability to enable them per app means a work window and a personal window do not have to carry the same set. The Guide covers those per app switches. Extensions are stored per profile, so a new window starts empty and needs the useful ones added once.

What to change first

Decide which half of GitHub takes the most time in a normal week, and set that half up properly rather than installing all three products and hoping. If the answer is files on disk, GitHub Desktop on macOS 12.0 or later is the whole answer. If the answer is reviews, issues, and pipelines, the browser is doing the work and deserves a window with its own icon and one fixed account. A builder such as Kagemusha handles the second case, and the Supported services list shows how the same pattern applies to the other services sharing that browser.