The ChatGPT Mac app, and when a browser window beats it

There is an official ChatGPT app for macOS, so the useful question is not how to build one. It is which of the available routes fits the machine in front of you, because the official app draws a hard line at macOS 14 and asks for a system permission that some Macs are not allowed to grant. A browser tab, a Safari web app, an installed Chrome app, and a purpose built wrapper all end up pointing at the same service, and they differ in ways that only show up weeks later. The differences are worth knowing before the icon goes in the Dock.

Two official apps now sit behind the same download link

On July 9 the desktop app was replaced. OpenAI's help pages describe the new ChatGPT desktop app as combining Chat, Work, and Codex, available for macOS and Windows, and state that the previous macOS desktop app has been renamed ChatGPT Classic and continues to be supported. No migration is required at launch.

That matters for anyone following older instructions. Screenshots and step lists written before July describe the Classic app, and the two are not interchangeable in what they do. The new one is the route to the agentic features and to Codex. The old one keeps working for people who only want the chat window and do not want a new set of behaviours arriving on a Tuesday.

The download page at chatgpt.com/download detects whether the Mac uses Apple Silicon or an Intel processor and serves the matching installer, so there is nothing to choose there. What is worth choosing deliberately is which of the two apps to keep on the machine, because both can be installed, and having both means two menu bar icons competing for the same keyboard shortcut.

Anyone writing internal documentation for a team should name the app explicitly rather than saying the ChatGPT app. That phrase now points at two different pieces of software with different feature sets.

The line that decides it for you: macOS 14

The system requirements are stated plainly: macOS 14 and either Apple Silicon, M1 or better, or an Intel processor. The Intel part surprises people who assumed the app was Apple Silicon only. The macOS 14 part is the one that ends the conversation on older hardware, and OpenAI's help page adds that no version compatible with older operating systems will be released.

Work out what that excludes. macOS Sonoma 14 is the first release the app requires, and Apple's compatibility list for Sonoma starts at the 2018 MacBook Pro and the 2018 Retina MacBook Air. A 2017 MacBook Pro or a 2017 MacBook Air tops out at macOS Ventura 13. Those machines are still perfectly capable of running a chat interface, and they will never run the official app.

Chrome, for comparison, lists macOS 13 Ventura and up as its requirement on Mac. So on a Mac stuck at Ventura, a window pointed at chatgpt.com is not a workaround for a missing feature. It is the only route that exists, and it happens to work well, because the service is a web application first.

The same reasoning applies to a managed Mac that a company keeps one major version behind for compatibility testing. The refresh cycle for that policy is measured in months. A browser based app window is available today on that machine.

What the Chat Bar does that a tab cannot

The strongest argument for the official app is the Chat Bar. By default it opens with Option and Space, it floats above whatever is on screen, it can be dragged anywhere on the desktop, and it can also be opened from the menu bar icon. From that bar, a new conversation can start with an attached file, a photo, or a screenshot taken on the spot, and the shortcut itself can be reassigned in Settings.

This is the piece a browser tab genuinely cannot reproduce. A tab requires switching to the browser, finding the right window among the others, and then finding the right tab within it. The Chat Bar removes all three steps and returns the screen to its previous state afterwards.

An app window built from a website removes only the second and third steps. The site gets its own Dock icon and its own entry in the application switcher, so it is reachable with Command and Tab like any other program, and it never hides behind a browser window full of unrelated tabs. That is a real improvement over a tab and a real step down from a global hotkey overlay. Which of the two is enough depends on whether the reader wants to ask short questions constantly or hold longer sessions a few times a day.

The distinction shows up in how the window is used. A floating bar suits a one line question answered in five seconds. A full window suits a conversation with attachments, code, and scrolling. People who mostly do the second thing report little benefit from the overlay.

Work with Apps, and the permission it asks for

The second thing the official app does that no wrapper can is read the app currently in front. OpenAI documents this as Work with Apps, available from version 1.2025.057 onward, covering text editors including Apple Notes, Notion, TextEdit and Quip, code editors including Xcode, the VS Code family and the JetBrains family, and terminals including Terminal, iTerm, Warp and Prompt. The app includes the last 200 lines of open panes, and if text is selected it focuses on the selection. Editing is available only with IDEs.

The mechanism is worth understanding before enabling it. For most apps the feature relies on the macOS Accessibility API, granted under System Settings, and VS Code additionally needs an extension installed inside the editor. Accessibility access is a broad grant. It is the same class of permission that automation and screen reading tools request, and it is exactly the permission many corporate device policies restrict.

Two consequences follow. On a managed Mac, the feature may simply not appear, and OpenAI notes that enterprise admins can turn off code edits on macOS from Admin Settings. And on a personal Mac, the content pulled from those panes becomes part of the chat history stored in the account until it is deleted.

None of that is an argument against the feature. It is an argument for deciding deliberately. A reader whose work is writing prose in a browser gets nothing from Work with Apps and still hands over Accessibility access if the toggle is left on.

There are documented edges around it too. Advanced Voice can be used while working with apps, but OpenAI notes that it cannot be launched from the companion window yet and that voice mode does not yet support code edits. Temporary Chat is the escape hatch for anything that should not persist, since conversations started that way are not saved to the account or used to improve the models. Both are the kind of detail that only matters once the feature is switched on, which is the argument for switching it on once, on purpose, rather than accepting a permission dialog during setup.

Where a wrapped chatgpt.com window still makes sense

Four situations come up repeatedly, and in each of them a site to app tool answers something the official app does not.

The Mac cannot run it. Covered above. Ventura and earlier have no official route.

Two accounts are in daily use. A personal account and a work account signed in at once is a common need, and the usual answer inside a single app is signing out and back in. Separate app bundles, each holding its own session, turn that into two icons in the Dock. Safari's web apps make this explicit: Apple documents that a web app shares no browsing history, cookies, website data, or settings with Safari, which is precisely what keeps two sessions from colliding.

Browser extensions are part of the workflow. Password managers, clipboard tools, and prompt libraries live in the browser. An app built on a Chromium browser already installed on the Mac keeps them. A separate native app does not have them at all.

The icon needs to be distinguishable. Several assistant tools installed side by side produce several similar icons at Dock size. Tools that build site specific apps let the name and the icon be set at creation time, which is one of the adjustable pieces listed on the Features page.

The three routes side by side

	Official app	Browser tab	Site to app window
Minimum macOS	14	Browser's own floor, macOS 13 for Chrome	Browser's own floor
Option and Space overlay	Yes	No	No
Reads your editor and terminal	Yes, with Accessibility access	No	No
Browser extensions apply	No	Yes	Yes, when built on an installed browser
Own Dock icon and switcher entry	Yes	No	Yes
Separate app per account	No	Per browser profile	Yes
Custom name and icon	No	Not applicable	Yes

The table is not a scoreboard. The top two rows and the bottom three rows rarely matter to the same person, which is why the argument about this keeps going in circles.

What breaks later, in each route

Every route has a failure mode that appears after the setup is forgotten.

The official app updates on its own schedule and occasionally changes what the overlay does. The July replacement is the clearest example, and a team that documented the old behaviour now has documentation describing an app that has been renamed.

A Safari web app is tied to Safari's engine and, by design, to its own isolated store of cookies. Signing in happens once inside the web app, separately from the sign in that already exists in Safari, and two factor prompts arrive again the first time.

A Chrome installed app belongs to the Chrome profile it was installed from. Delete the profile and the app is gone. Chrome also notifies when a web app wants to update its name or icon and offers to accept, ignore, or uninstall, which means the label under the Dock icon is not permanently under the reader's control.

A dedicated builder sits between those. The app keeps working across browser updates because it borrows an engine already on the machine, and the name and icon are set locally rather than fetched from the site. The trade is that it has no privileged access to the operating system, so nothing resembling Work with Apps is possible. The Guide walks through what setting one up involves, and the Pricing page states what a licence covers.

What to change first

Check the macOS version before anything else, because it removes options rather than adding them. On macOS 14 or later, install the official app, use it for a week, and then decide whether Accessibility access is something worth granting for the editor integration or whether the overlay alone was the point. On macOS 13 or earlier, or with two accounts in play, build the window from the browser already installed and give it a name short enough to find in Spotlight. Either way, do it once and stop reconsidering, with Kagemusha or with the browser's own install command.