Is there one official Claude Code app for Mac?

There are several official surfaces rather than one app: the command line tool, the Code tab in Claude Desktop, extensions for VS Code and JetBrains, and cloud sessions in the browser. The documentation describes them as connecting to the same engine, and they share project settings.

Which surface should be installed first on a Mac?

The command line version is the safest first install. It is the only surface that supports scripting and every permission mode, the JetBrains plugin requires it, and the native installer keeps it updated automatically. Other surfaces can be added later without changing anything.

Does the VS Code extension work in Cursor?

Yes. The documentation lists a direct install link for Cursor, and the extension also installs in other VS Code forks through the Open VSX registry. If an editor cannot install it, running `claude` in the editor's integrated terminal works instead.

Can Claude Code keep working after the Mac is closed?

Local sessions stop when the machine sleeps. Cloud sessions, started from claude.ai/code, the mobile app, the desktop app with Cloud selected, or `claude --cloud`, run on managed infrastructure and continue after the laptop is closed. They work on a GitHub clone rather than local files.

Do settings have to be set up separately for each surface?

No. CLAUDE.md files, MCP servers, hooks, skills and the settings in `~/.claude/settings.json` are shared across the terminal, desktop app and editor extensions. Keeping rules in these files rather than in app toggles makes every surface behave the same way.

Where Claude Code can run on a Mac and how to choose between terminal, desktop and editor

Searching for a Claude Code app on a Mac turns up several things at once: a desktop download, a command line installer, an editor extension, a browser address and a phone app. They look like competing products. They are not. The official documentation describes each of them as a surface that connects to the same underlying Claude Code engine, so a project's CLAUDE.md, its settings and its MCP servers work across all of them.

That makes the choice less about features and more about where the work already happens. This guide lists the places Claude Code can run on a Mac as of September 2026, what each one needs installed, what it is good at, and a way to pick without trying all of them. Facts are taken from the documentation at code.claude.com. All of them require a paid Claude plan (Pro, Max, Team or Enterprise) or a Console account; the free plan does not include Claude Code.

The five places it runs

The terminal. The command line tool, started by typing claude in a project folder. It is the original surface and the most complete one. Installed with a one line native installer or with Homebrew.

The desktop app. Claude Desktop has three tabs, and the one called Code is Claude Code with a graphical interface. It adds a sidebar of parallel sessions, a diff view, a terminal pane, a file pane and a browser pane for previewing apps. It is a universal build for Intel and Apple Silicon Macs.

VS Code and its forks. An extension for VS Code (1.94.0 or later) that also installs in Cursor and other forks. It opens a chat panel inside the editor with inline diffs, plan review and file mentions that include line ranges from the current selection.

JetBrains IDEs. A plugin for IntelliJ IDEA, PyCharm, WebStorm, GoLand, Android Studio and others. It runs the claude command in the IDE's terminal and connects to it, showing changes in the IDE's own diff viewer.

The cloud. Sessions that run on infrastructure managed by Anthropic rather than on the Mac, started from claude.ai/code in a browser, the Code tab in the Claude mobile app, the desktop app with Cloud selected, or the terminal with claude --cloud. They keep running after the laptop is closed. The documentation marks cloud sessions as a research preview.

What each one needs installed

The installation story differs more than the features do, and it is where most setup confusion comes from.

Surface	What to install	Includes the `claude` command?
Terminal	Native installer or `brew install --cask claude-code`	Yes
Desktop app	Claude Desktop from claude.com	No, install the command line version separately
VS Code, Cursor	The Claude Code extension	Bundles its own copy for the chat panel only
JetBrains	The command line version, then the plugin	Requires it; the plugin does not bundle one
Cloud	Nothing locally; a GitHub connection	Not applicable

Two rows cause most support questions. The desktop app includes Claude Code, so Node.js and the command line tool are not needed to use it, but installing it does not make claude available in a terminal. The VS Code extension bundles a copy of the command line tool for its own panel, but running claude in VS Code's integrated terminal still requires the standalone install. The JetBrains plugin works the other way: it needs the standalone install on the PATH and shows a "Cannot launch Claude Code" notice if it is missing.

The simplest arrangement for most Mac users is to install the command line version first, with the native installer, which updates itself in the background. Every other surface can then be added on top without any of them being the odd one out.

What each one is good at

The documentation's own guidance is short: use the desktop app to manage parallel sessions in one window, arrange panes and review changes visually, and use the command line for scripting, automation or a terminal workflow. The editor extensions sit between them. In more detail:

Terminal is the only surface with everything. Non-interactive runs with claude -p, output formats for piping into other tools, the dontAsk permission mode for locked down automation, agent teams, and every enterprise cloud provider. It starts fastest and works over SSH on any machine. What it lacks is visual review; changes are read with git diff or in another app.

Desktop app is strongest when several tasks run at once. Each session can take its own Git worktree so parallel work does not collide. The diff view accepts comments on individual lines, which Claude reads and acts on. Images and PDFs can be attached to prompts. Scheduled tasks and pull request monitoring are built in. It is interactive only, so it cannot be called from a script.

VS Code and JetBrains suit people who already spend the day in that editor. The conversation sits next to the code, the current selection is shared automatically, and diffs open in the editor's own viewer. JetBrains also lets Claude read the IDE's inspection diagnostics such as lint errors.

Cloud is for work that should not tie up the Mac: long refactors, migrations, test suites, or tasks started from a phone. Sessions can span more than one repository. It requires the code to be on GitHub, and the session works on a clone rather than on local files.

Choosing by the shape of the work

Features overlap enough that a checklist does not settle it. Four questions usually do.

Where is the day already spent? Someone who lives in VS Code will get more from the extension than from switching to a separate window. Someone who lives in a terminal multiplexer will find the command line natural. Adding a surface that means another window to watch is a cost.

Does anything run unattended? Scripts, Git hooks, CI jobs and cron entries can only use the command line. If any part of the workflow is automated, the command line has to be installed regardless of what else is used.

How is the result checked? If checking means reading a test result, any surface works. If it means looking at a rendered page, reviewing a change across many files, or comparing two attempts side by side, the desktop app's panes and diff comments save time.

Is the work code at all? Claude Code is often used on folders that are not software: research notes, document sets, exported data, image assets. For that work the editor extensions add little, because there is no code editor involved. What matters is seeing the folder and the session together. The desktop app's file pane is for spot edits to files Claude touched. A file manager with a built-in terminal runs the command line version next to the folder itself, which fits file work more closely. The comparison of file managers sets out how the options differ.

Mixing surfaces without confusion

Most people end up using two surfaces, and that works well because they share configuration. The project's CLAUDE.md and CLAUDE.local.md, MCP servers in .mcp.json, hooks, skills and the permission rules in ~/.claude/settings.json apply to the terminal, the desktop app and the editors alike. Putting rules in these files, rather than in per app toggles, is what keeps behavior consistent.

Sessions can also move between surfaces:

/desktop in a terminal session hands it to the desktop app on macOS when signed in with a subscription.
/resume in the desktop app lists and continues sessions started in the terminal.
claude --cloud starts a cloud session from the terminal, and the documentation describes --teleport for bringing a cloud session back to the local machine.
Remote Control lets a local session be steered from a phone or another device while it keeps running on the Mac.

One caution when two surfaces work on the same project at the same time: they can edit the same files. The desktop app's worktree option, or the command line's --worktree flag, gives each session its own copy of the repository so the edits only meet at commit time.

A common combination on a Mac is the terminal for quick questions, commits and automation, and the desktop app for longer tasks where review matters. People who work mostly in one editor tend to settle on the extension plus the terminal instead.

Things that differ between surfaces

A few details behave differently depending on where Claude Code runs, and they explain most "it works here but not there" reports.

Environment variables. The desktop app, launched from the Dock, reads PATH from the shell profile but not other exported variables. The terminal inherits everything.
Interactive commands. Commands that open a panel in the terminal, such as /permissions, reply that they are not available in the desktop app's Code tab. Editing the settings file works everywhere.
Permission modes. All modes are available in the terminal. The desktop app offers Manual, Accept edits, Plan and Auto, with bypass available only after it is enabled.
Third party providers. Amazon Bedrock, Google Cloud and Microsoft Foundry are supported directly in the terminal. The desktop app needs a separate gateway setup.
Attachments. The desktop app accepts images and PDFs. The terminal takes text and file references.

Trying a second surface without disrupting the first

Because the surfaces share configuration, adding one is low risk, but a little order makes the trial more useful than simply opening a new window.

Start by moving anything that currently lives in one surface's settings into the shared files. Permission rules that should hold everywhere belong in .claude/settings.json in the project or ~/.claude/settings.json for the user, where every surface reads them. Writing the project's build and test commands into CLAUDE.md means the new surface starts with the same knowledge as the old one, and the comparison is fair.

Then pick one real task, not a demonstration, and run it in the new surface from start to finish. A task that involves reviewing a change across several files is a good test of the desktop app. A task inside a file already open in the editor is a good test of the extension. A long running job that would normally keep the Mac busy is a good test of a cloud session. The point is to see whether the surface removes a step that was costing time, not whether it has more buttons.

Finally, check the result the same way as before. If the usual habit is git diff in a terminal, run it after the trial too. Surfaces differ in how they present changes, and a new presentation can hide something the old one showed. Once a surface has handled a few real tasks and the review still feels complete, it has earned a place. If it has not, uninstalling it changes nothing for the others, since each keeps its own session list and the shared files stay where they are.

What to change first

Install the command line version with the native installer, since every other surface either depends on it or benefits from having it. Then add one visual surface that matches where the day is spent: the editor extension for code, the desktop app for parallel tasks. If the work is mostly folders and files rather than code, Atriens keeps a terminal and the folder in one window on the Mac.