Claude Code CLI: Terminal, IDE, Desktop or Web?

The Claude Code CLI is the claude program in your terminal. It is the same software as the VS Code extension, the desktop app and claude.ai/code in a browser. So you are not choosing between four tools, you are choosing between four ways into one tool. The question is not which one is best, but which one can reach what you need right now.

Anthropic calls the four entry points surfaces, and one sentence in its documentation decides the whole thing: each surface "connects to the same underlying Claude Code engine, so your repo's CLAUDE.md files, settings, and MCP servers work across all of them" (Overview).

We run this website on it, so what follows is not an opinion but a count: which surface actually wrote the 224 commits in this repository.

What is the Claude Code CLI?

The CLI is the command-line program claude. You start it in a project directory, and it reads the code there, edits files, runs commands and commits. Anthropic describes it as "the full-featured CLI for working with Claude Code directly in your terminal".

You can check for yourself that the other surfaces are the same program. This article is being written in a cloud session in a browser, and inside that container claude --version answers 2.1.289 (Claude Code). Not a second product, not a cut-down mode, the same version number a terminal on your own machine prints.

Two things only the CLI can do, which is why it has not been replaced by the three graphical surfaces:

• Pipe and script. cat logs.txt | claude -p "explain this" takes input, answers and exits. That is the shape Claude Code takes inside a shell script or a CI pipeline.
• Start everything else. claude --cloud "task" creates a cloud session, claude --desktop opens the desktop app in the current directory, and claude --teleport pulls a cloud session back into the terminal.

Installing it is one command, on macOS, Linux and WSL curl -fsSL https://claude.ai/install.sh | bash. The places where people get stuck doing that, Windows above all, we walked through one by one in Install Claude Code.

Which surfaces are there and what separates them?

Four: terminal, IDE extension, desktop app and web. They differ in three ways, and only the third one really decides anything, namely what the surface can reach.

Surface	Local install	How you drive it	Can reach
Terminal (CLI)	yes, one command	text, pipeable, scriptable	your local files
VS Code, JetBrains	VS Code ships it, JetBrains needs the CLI	inline diffs in the editor	your local files
Desktop app	yes, and it includes the CLI	diffs visually, sessions side by side	your local files and the cloud
Web, claude.ai/code	none	browser and phone	a repository on GitHub

The first three rows work on your hard disk. The fourth one does not: a cloud session runs in an isolated VM managed by Anthropic and clones your repository from GitHub. Whatever you have changed locally and not pushed, it cannot see.

Which gives you the decision rule, and it is shorter than any feature table: if you are working on files that exist only on your machine, you need one of the first three rows. Everything else is taste.

Which surface actually wrote this repository?

Almost always a local one: of the 203 commits Claude Code co-wrote, 195 came from a local surface and 8 from a cloud session, so 96 percent local. We counted it, because otherwise the question stays a claim. Commits made in a cloud session carry a Claude-Session: line in the commit message and local ones do not, which is a trace you can audit afterwards.

The 21 commits without that line are 13 merge commits from pull requests and eight early commits from before today's signature, so they sit outside the comparison. The ratio looks like a clear verdict for the terminal. It is not a verdict about quality though, it is one about the job. Because the eight cloud commits are not scattered at random: all eight of them are publications of this blog. Every other piece of work on this project, from the pricing logic through the webinar pages to the database, was made locally.

So the surface follows the task, not the preference. A job that has to start at seven in the morning without us cannot run on a laptop that is shut. A job where we want to see a change in a browser before releasing it belongs where the browser is.

When do you use the terminal?

When you are working on the project itself and need the feedback immediately. That is the normal case, and it is why the top bar above is so much longer than the others.

The terminal is also the only surface you can build Claude Code into something else from. claude -p prints an answer and exits, so it drops into a pipe, a shell script or a CI job. The Agent SDK comes from the same corner and builds custom agents on the same tools. What an agent actually is, and how to tell whether something really is one, is in What is an AI agent.

There is a practical point on top of that: the CLI is the only surface that exists everywhere. The desktop app runs on macOS and Windows and is still in beta on Ubuntu and Debian, and the /desktop handoff works only on macOS and x64 Windows. Every system has a terminal.

When do you use the IDE extension?

When you want to see changes line by line in the editor you are already working in. The VS Code extension provides, in Anthropic's words, "inline diffs, @-mentions, plan review, and conversation history directly in your editor".

One detail costs people time during setup if they do not know it: for JetBrains IDEs, "the plugin requires the Claude Code CLI, installed separately". The VS Code extension you install from the marketplace instead. Anyone coming from PyCharm or IntelliJ who installs the plugin without the CLI tends to look for the fault in the wrong place.

Technically the extension is the same CLI with a view in front of it. That is also why it does not appear separately in the count above: a commit from the IDE looks exactly like a commit from the terminal, because it is the same process writing it. That is not a hole in our measurement, it is the point of this article.

When do you use the desktop app?

When you have several sessions running at once, or you would rather look at diffs than read them. The app is meant for "running Claude Code outside your IDE or terminal" and can review diffs visually, run multiple sessions side by side, schedule recurring tasks and start cloud sessions.

Two sentences from the documentation are worth more at the start than the feature list:

1. "The app includes Claude Code, so you don't need to install the CLI separately." If you start with the desktop app, you already have the CLI.
2. A paid subscription is required. What the different ways in cost and when which plan pays off we took apart in Claude Code Kosten, and the cost calculator works out your own case.

The desktop app is also the only surface that can send a running local session into the cloud. You cannot do that from the CLI, and that is the difference the next section turns on.

When do you use the web surface?

When the task is supposed to carry on without you. Anthropic names three cases: kick off long-running tasks and check back later, work on repositories you do not have locally, and run several tasks in parallel. There is a fourth that only appears as a clause and matters most to us: routines, meaning scheduled runs, each execute as a cloud session.

That is exactly what our blog directory shows. Of the 15 article files in this repository, a scheduled cloud session created 12:

The three local files are the first two articles, still written by hand. After that a schedule took over. That is the point where the web surface stops being a more comfortable version of the terminal and becomes the only thing that works: a run at 08:07 needs no computer switched on.

That does not automatically mean the same for you. The web surface pays off as soon as a task runs longer than your attention, or as soon as it comes back on a regular basis. For the change you can see in two minutes, it is the detour.

How does a task move between surfaces?

One direction happens by itself, the other does not. This is where most guides get vague, and it decides where you should start a task.

Three rules sit in that picture that you otherwise learn the expensive way:

• The cloud clones GitHub, not your folder. claude --cloud clones the GitHub remote of your current directory at your current branch, not your local checkout. Push first, or you send a task off against an old state.
• The handoff from the CLI is one-directional. --teleport pulls a cloud session into the terminal, but a running terminal session cannot be pushed to the cloud from there. Only the desktop app can do that, from its menu.
• Teleport checks four things before it takes over: a clean git status, the same repository rather than a fork, a branch that has been pushed, and the same account.

What can the web surface not do?

It cannot reach your local files, and it does not have every command. Both follow from the fact that it runs in somebody else's VM, and both are named in the documentation rather than hidden.

The third row surprises people most often. A cloud session is not an open machine on the internet: network access is limited by default and can be switched off entirely. That is an obstacle while you set it up, and in production it is the reason a session like that can be left running unattended.

What stays the same on all four surfaces?

Everything that lives in the project. The surface brings the controls, the project brings the rules, which is why switching between terminal and browser is not a move but a different door into the same setup.

In this repository that is a single file at the root: a CLAUDE.md of 431 lines and 3,836 words, holding 32 numbered or bulleted rules (counted on 5 Oct 2026). It describes why the routes have to stay static, which numbers are sourced and which wordings are banned. The cloud session writing this article read the same file a terminal on Marco's machine reads, and both are held to the same 32 rules.

That is why the choice between surfaces matters less than it looks. What makes your tool good does not sit in the surface, it sits in that file. Trying a second surface costs you minutes. Writing a good CLAUDE.md costs you an afternoon and pays out everywhere afterwards.

Which surface should you install first?

The CLI, whichever one you end up using daily. Three reasons, in this order:

1. It is the prerequisite for two of the others. The JetBrains plugin needs it anyway, and --cloud, --teleport and --desktop all assume a signed-in CLI.
2. It runs everywhere. The desktop app does not exist for every system, a terminal does.
3. It forces you into the setup all the others then share. CLAUDE.md, settings and MCP servers live in the project and apply across every surface. Write them once properly and you have them everywhere.

Then a second step pays off that has nothing to do with the surface: taking the recurring working methods out of CLAUDE.md and putting them into their own versioned files. Where we draw the line between the two is in Claude Code Skills. How to build an instruction that does the same thing on every surface is what the prompt generator writes for you.

If you would rather run through the four surfaces on a live project than read about them, from the first claude in a terminal to a scheduled run in the cloud, that is the hands-on part of the Claude Code System.