A Copilot desktop app on a Mac: one window beside your work

A copilot desktop app mac search usually ends in a download button and an unanswered question. There is a signed build from Microsoft in the Mac App Store, there is copilot.microsoft.com in a browser tab, and the two are not the same product with a different coat of paint. One of them is missing features the other has. One of them can hold a second account without a fight. Deciding between them takes about five minutes once the differences are on the table, and the decision holds for every other site that lives permanently in a tab.

What Microsoft actually ships for macOS

The Mac App Store listing is from Microsoft Corporation, is free with in-app purchases, and is filed under Productivity. It weighs 128.9 MB, and the compatibility line reads Requires macOS 14.0 or later. The version on the listing is 25.7.440902001, dated 3 September, and the interface is available in English plus 32 more languages including Japanese, German, and Simplified Chinese. The age rating is 13+.

The in-app purchases on that listing are not Copilot subscriptions with Copilot names. They are Microsoft 365 Personal at $9.99 and $99.99, and Microsoft 365 Premium at $19.99 and $199.99. That tells a reader something useful before installing anything: the paid tier behind this app is a Microsoft 365 plan attached to a Microsoft account, not a per app licence bought once.

The listing also states that the developer supports VoiceOver, Voice Control, a dark interface, differentiation without colour alone, sufficient contrast, and reduced motion. For an app that is going to sit open all day beside other work, that list matters more than the feature bullets.

None of this describes GitHub Copilot, which is a separate product for writing code. The word is shared; the applications are not. A reader who came looking for code completion in an editor is in the wrong listing.

The three things the Mac build adds

Microsoft documents the macOS app as a superset of the website, and the documentation is specific about what that means. The support page states that the macOS app supports generally the same features available at copilot.com, with three additions.

The first is a system wide shortcut. Press Option and the Spacebar to bring up Copilot at any time, and the combination can be changed or removed entirely under Account, then Keyboard Shortcut. A global shortcut is the one thing a browser tab cannot offer, because a tab has no standing outside the window it lives in.

The second is appearance. By default the theme of the app follows the macOS appearance setting, and Day or Night can be chosen manually under Account, then App Appearance.

The third is device context. The documentation gives the example of asking which shortcut key takes a screenshot, and states that the answer is tailored to the current operating system. This is a small feature with an outsized effect on how often the app gets used, because it turns the window into a place to ask about the machine rather than only about the world.

The two things it leaves behind

The same page names the omissions plainly: Copilot Pages and Deep Research are not currently available in the macOS version. Both are features a heavy user reaches for, and neither has a workaround inside the app.

This is the fork in the road. A reader whose daily work involves collaborative pages or long research runs cannot treat the Mac App Store build as a complete replacement for the site. They will end up with the app open for quick questions and a browser tab open for the two missing features, which is exactly the tab sprawl the app was supposed to fix.

The alternative is to stop treating the site as a browser tab and start treating it as an application. macOS has two built in ways to do that, plus a third route for people who need more control, and all three give the full website rather than a subset of it.

Putting the site itself in its own window

Safari has this built in. Apple documents the route as going to the website, clicking the share control in the toolbar, choosing Add to Dock, then clicking Add. The resulting icon appears in the Dock and in Spotlight Applications, the window carries a simplified toolbar, and notifications arrive the way they do from any other app. Apple's page also notes that if the website was already signed in, the web app is signed in automatically in most cases, with the same user name and password.

What gets missed is that a Safari web app has its own settings panel. Open the app, click its name in the menu bar, choose Settings, then Privacy, and there are controls for camera and microphone access, screen access, location, clearing that app's website data, and notification behaviour in Notification Center. Apple notes that the Notifications option only appears after the website has prompted for permission. That is a per app boundary, not a per browser one.

The Chromium route works differently. Desktop installation is supported by Google Chrome and Microsoft Edge on macOS, and those browsers show an install badge in the address bar when a site declares itself installable. There is a detail worth knowing before trying it here: copilot.microsoft.com serves no web app manifest. Nothing on the page tells the browser what the application should be called or which icon to use.

Install is still possible. Chrome allows a site to be installed even when it does not meet the installability criteria, and only the standalone and minimal-ui display modes exist on desktop anyway. The result is a real window with a real Dock icon that appears in Spotlight, can carry a badge number, and cannot be installed twice in the same browser. Safari's Add to Dock does not read a manifest at all, which is why it works identically on sites that were never built with installation in mind.

Four containers, side by side

Container	Full site features	Second account	Global shortcut	Signs in as
Mac App Store app	No. Pages and Deep Research absent	One signed in account	Yes. Option and Spacebar	Its own account
Safari Add to Dock	Yes	Yes. Build two web apps	No	Its own web app session
Chrome or Edge install	Yes	Shares the browser profile	No	The browser profile's account
Per app browser profile	Yes	Yes. One profile per app	No	That app's own profile

The table has one asymmetry worth reading twice. The only row with a global shortcut is the row that is missing features, and the only rows that keep the full site are the rows built out of a browser. There is no container that gives both.

Accounts decide this, not features

The question that settles the choice is not which container looks nicer. It is how many Microsoft accounts are in play.

One account, personal, nothing else signed in on the machine: install from the Mac App Store, accept the two missing features, and enjoy the Option and Spacebar shortcut. It is the shortest path and the least maintenance.

A work account and a personal account, or a client tenant beside an employer tenant: the Mac App Store build holds one signed in identity at a time, so it will become a switching chore. Two Safari web apps built from the same URL keep separate sessions, which is the cheapest answer. A tool that assigns a browser profile per app does the same thing while keeping Chromium extensions available inside each window, and the Guide walks through what changes when the same site is built twice.

Whichever route wins, the interesting part is that the decision generalises. A ticket queue, a payroll console, a status dashboard, an analytics view: all of them raise the same three questions about identity, notifications, and what happens when the wrong window is closed. The Supported services list is worth reading as a prompt for which of those already live permanently in a tab.

What a window gets that a tab never had

The features that separate an application from a tab are mostly unglamorous, and they are the ones that decide whether a habit sticks.

Notifications are the clearest example. A Safari web app gets its own row in Notification Center with its own name, and its own controls for when not to be disturbed. Chromium installs can set a badge number on the Dock icon through the Badging API and can attach a contextual menu to the icon with App Shortcuts. A tab has none of that, because a tab is not addressable by the operating system.

Search is the second. Installed web apps appear in Spotlight on macOS, so the window can be summoned by typing its name rather than by hunting through a browser window. Apple's documentation states that an Add to Dock web app lands in both the Dock and Spotlight Applications.

Keyboard behaviour is the third, and it is where a tab actively gets in the way. Inside a Safari web app, Command-F searches the app, Command-P prints the current screen, Option-Command-C copies a link to the current page, Option-Tab moves through links and controls, and Command with the up or down arrow jumps to the corner of the app. In a browser window, several of those keys belong to the browser rather than to the site.

Chromium adds one more that is easy to miss. After installing, going to about:apps, right clicking the app, and choosing Start App when you Sign In makes the window open with the machine. An app that reopens on every login gets used; a tab that has to be found again does not.

The things installing will not fix

An honest account of this has to include the parts where the container makes no difference at all.

The model behind the answers is the same in every container, because every container is showing the same service. Response quality, refusal behaviour, and the length of a reply are decided by the account and the plan, not by the window frame. Moving the site from a tab into a Dock icon changes none of it.

The plan is the same too. The purchases named on the Mac App Store listing are Microsoft 365 Personal and Microsoft 365 Premium, which are account level subscriptions. Buying one through the app and buying one through the site land in the same place, and cancelling in one place cancels in both.

The missing features stay missing. Copilot Pages and Deep Research are absent from the macOS app regardless of how the app is launched, pinned, or shortcut. Any workaround involves the website, which is the argument for building the container out of the website in the first place.

Extensions are the one place where the route genuinely changes the answer. A Safari web app runs Safari extensions, enabled per app from its own Extensions settings. A Chromium install inherits the extensions of the browser profile that created it. A tool that assigns one browser profile per app lets each window carry a different extension set, which is how a content blocker can be on in one window and off in another. The Pricing page is where the practical limits of that approach are set out.

What to change first

Count the Microsoft accounts in use, then pick the row from the table that matches. One account takes the Mac App Store build and the global shortcut. Two or more takes a container with its own session, and the Kagemusha feature list describes how a per app browser profile keeps those sessions from colliding.