Claude AI app for PC: what the desktop build gives

Unlike most of the assistants people search for, this one has a real answer. A desktop application is published for Windows, for macOS, and in beta for Linux, and it is free to download regardless of plan. That settles the existence question in a sentence. The useful question sits one step past it: the download that arrives today is considerably larger in scope than the chat window most people are picturing, and whether that scope is welcome depends entirely on what the machine is being asked to do.

The answer to the existence question, and the question underneath it

The download page lists five desktop targets. macOS, Windows on x64, Windows on arm64, ChromeOS, and Linux with a pointer to documentation rather than a direct file. Mobile builds for iOS and Android sit alongside them, and a separate research oriented build in beta offers its own downloads split between Apple silicon and Intel Macs.

That breadth is unusual. Plenty of well known services have no desktop application at all: Google Calendar states as much in its own help pages, and X has no Mac entry in its App Store listing. Others have one but drew the supported line high, with the ChatGPT desktop application requiring macOS 14 and the Gemini one requiring macOS 15 on Apple silicon. Measured against that group, this download is the permissive end of the range.

So the decision is not whether to install it. It is whether the installed thing is the right shape for the way the service actually gets used. That is a narrower question, and it has a different answer for someone who runs long agentic tasks than for someone who asks a dozen questions a day and wants them out of the browser.

The version floors, stated plainly

The published system requirements are short enough to quote in full.

macOS 11 (Big Sur) or higher Source: support.claude.com

Windows is listed as Windows 10 or higher. The Linux beta is listed as Ubuntu 22.04 LTS or later, or Debian 12 (bookworm) or later, on x64 or arm64.

Platform	Minimum version	Notes
macOS	macOS 11 (Big Sur)	Universal build covers Intel and Apple silicon
Windows	Windows 10	Separate arm64 download published
Linux	Ubuntu 22.04 LTS or Debian 12	Beta

A macOS 11 floor is worth pausing on. Big Sur shipped in 2020, which means Macs that were cut off by other AI desktop applications years ago still qualify here. An Intel MacBook Pro running Monterey, a machine that cannot install the Slack desktop application and cannot install Google's Drive client, can install this one. The Universal build removes the Intel question entirely rather than shipping a separate architecture specific file, which is a different approach from the research build that splits Apple silicon and Intel into two downloads.

Windows 10 as the floor has a similar effect on that side. There is no requirement for Windows 11, no requirement for a specific processor generation, and an arm64 build for the Snapdragon based machines that have appeared in the last two years.

What arrives with the download

This is the part that has changed most, and the part worth checking before installing on a work machine. The desktop build is no longer a chat window with a menu bar. It carries three things: the conversational interface, an agentic workspace that operates on files and connected applications, and a coding environment.

The macOS documentation is explicit that the agentic workspace is not optional at install time. It is described as being installed automatically alongside the desktop application. On Windows and macOS both, the application also serves as an entry point to the coding tooling, with the download page listing terminal, editor, and Slack surfaces next to the desktop one.

The consequence is a bigger application than the chat interface alone would justify, with more permissions requested and more moving parts to update. For someone who wants the agent to open files and act on them, that is the entire point and the reason to install. For someone who opens the assistant to ask questions and paste text back out, most of what arrived is dormant.

Distribution details follow from this. On macOS the application installs to /Applications and updates itself unless an enterprise policy disables that behaviour. Two installer formats are published, a .pkg aimed at managed deployments and a .dmg for the ordinary drag and drop route. Installing into the system applications folder requires administrator access, while a per user install under the home directory allows updates without one. On a locked down corporate Mac that distinction decides whether the application can update itself at all.

Not in either store

Neither the Mac App Store nor a Microsoft Store listing carries this application. A search of Mac App Store business and productivity results returns Microsoft, Canva, LINE and similar publishers, and nothing from Anthropic. The distribution channel is direct download from the vendor site.

That has three practical effects. Updates arrive through the application's own updater rather than through a store queue, so a machine that blocks outbound update checks silently falls behind. Gatekeeper handling depends on the vendor's signing and notarisation rather than on store review, which is normally invisible but occasionally produces a first launch prompt. And organisations that whitelist software by store identifier need a different mechanism here, which is precisely why the .pkg installer exists.

None of that is a defect. It is the standard shape for developer facing software on the Mac, and the same shape Google and Slack use for their direct downloads. It is simply worth knowing that the store is not the place to look.

Where a plain window fits better

Three situations come up repeatedly, and none of them is solved by the official application.

The first is two identities. One desktop installation signs into one account. Somebody with a work seat under a company plan and a personal subscription cannot have both open side by side in the official application, which means switching, which means losing the thread that was open. Two separate windows, each bound to a different browser profile, hold both at once.

The second is weight. On an older machine with 8 GB of memory, an application carrying an agentic workspace and a coding environment competes with the editor and the browser that are already open. A window that is just the conversation, running on the browser engine already resident in memory, costs a fraction of that.

The third is everything else on the screen. The assistant is rarely the only browser based tool in a day's work. A project tracker, a documentation site, an internal dashboard, a mail client: they all live in the same undifferentiated row of tabs. Solving the problem for one service and leaving the other eight buried does not change how the day feels. A catalogue of ready made services makes the scale of that visible faster than counting tabs by hand.

What a browser based window keeps

The distinction that matters between wrapper approaches is what sits underneath. A window built on the Chromium browser already installed inherits the signed in session, so no fresh login is needed, and inherits the extensions, so password managers and clipboard tools keep working. It also inherits the browser's update cycle, meaning security fixes arrive without a separate update path.

A wrapper that bundles its own engine does none of that. It starts logged out, extensions do not carry over, and each application updates on its own schedule. For an assistant behind single sign on, that first login is the friction people feel immediately.

The problem an installer genuinely solves

It is worth being precise about what installing anything as an application buys, because the benefit is often described vaguely and it is actually quite specific.

An application gets its own entry in the Command Tab switcher. A browser tab does not. On a Mac with a browser, an editor, a terminal, and a chat client open, Command Tab cycles through four items. Add fifteen browser tabs and it still cycles through four, with all fifteen collapsed behind one browser icon. Reaching a particular tab means selecting the browser, then finding the tab by favicon or by a separate tab search shortcut. That is two or three actions instead of one.

An application gets a Dock icon that can be assigned a position and kept there. It gets its own window that remembers size and placement across restarts. It can be assigned to a specific desktop space, so it always appears on the same screen. It can be given a system wide keyboard shortcut through the accessibility and shortcut settings, so a single key combination brings it forward regardless of what is in focus. A tab has none of these properties.

It also gets its own notification identity. Notifications from a browser tab arrive attributed to the browser, and muting the browser mutes everything at once. Notifications from a separate application can be muted or allowed on their own.

These are small individually and cumulative in practice. They are also the reason people keep searching for desktop applications of services that never shipped one. The desire is not for a different rendering engine. It is for the four or five window management behaviours listed above.

Before installing on a managed machine

On a work issued laptop, two checks are worth doing first, because both are easier to answer before installation than after.

The first is whether the agentic component is acceptable under the organisation's policy. It operates on local files and connected applications by design, which is a different risk profile from a chat window. Some security teams have a position on this and some have not thought about it yet, and the answer is easier to get in advance.

The second is the update path. If the application lands in the system applications folder and the account lacks administrator rights, self updating may fail silently and the version will drift. Installing under the user's own applications folder avoids that, at the cost of the software being present for one account rather than all of them.

Neither check applies to a personal machine, where the sensible approach is to install it, try it, and remove it if the footprint is unwelcome.

Running both is normal

These are not competing choices. The official application is the right tool for agentic work, file access, and anything involving the coding environment. A standalone window is the right tool for keeping the conversation reachable in one keystroke without hauling the rest along.

A reasonable arrangement is the official application installed for the heavy work, and a lightweight window for the second account or for the quick question. Setting up the second one takes a couple of minutes, and the guide covers the sequence.

What to change first

Check which of the two jobs is actually needed. If files and agents are involved, install the official build and accept its footprint. If the need is a conversation window that opens instantly and holds a second account, Kagemusha builds that on the browser already installed.