Claude Code everywhere: CLI, IDE, desktop, web

For my first month with Claude Code I lived entirely in the terminal, and I assumed that was the tool. Then I realized the same agent, with the same setup I had built, was also sitting in a desktop app and on the web, and I had been treating one door as the whole house.

That is the thing to get: Claude Code is one agent behind four doors, the CLI, an IDE extension, a desktop app, and the web. Same behavior, same project setup, wherever you open it.

So the only real question is which door fits the work in front of you, and the answer changes through the day. Here is how I pick.

One agent, four doors

Claude Code shows up in four places, and the important part is what does not change between them: your CLAUDE.md, your skills, your permissions all apply across the CLI, the IDE, the desktop app, and the web. Switching surfaces does not mean reconfiguring or losing your context. You built the setup once; it follows you.

That is why choosing a surface is a low-stakes decision. You are not committing to a tool, you are picking an entrance for this particular task, and you can walk in a different one an hour later.

The phrase same agent is doing a lot of work here, so be clear on what it means. It is not four apps that happen to share a name. It is one Claude Code, and your setup, the CLAUDE.md brief, your skills, your connected MCP servers, your permissions, comes with it. Move from the terminal to the web and you are not re-onboarding a new tool, you are the same operator picking up the same work through a different door.

CLI: the fastest way in

The terminal is home base. You run claude in a folder, give it a task, and watch it work. It is the lowest-friction way to start a scoped job, and it is where a lot of the power lives, so if you are building a repeatable GTM task, the CLI is usually where you build it.

It looks intimidating from the outside and is not once you are in. You type in plain language; the terminal is just the frame around the conversation, not a language you have to learn.

The CLI is also where the power users live, because typing is faster than clicking once the commands are muscle memory. You launch it in a folder and everything in that folder is fair game. For a GTM operator that folder is your workspace of account lists, notes, and scripts, so the terminal is less a developer thing and more the fastest way to point Claude at your actual work.

IDE and desktop: work where your files are

The IDE extensions bring Claude Code into VS Code or JetBrains, so it sits right next to the files and sees your edits in context. If you are working inside a repo, of prompts, of skills, of the scripts that run your GTM data, that proximity is worth a lot.

The desktop app is the full application: connectors, multiple sessions, always-open. For a GTM operator it is often the daily home, Claude Code running beside your CRM and docs, connected to your stack, rather than a thing you launch and quit.

The reason to work in the IDE or the desktop app is proximity to the files. When you are editing a scoring script or restructuring a data pipeline, seeing the change land in the editor next to the agent's explanation closes the loop tighter than a terminal can. The desktop app adds the connectors and local-file reach that make it a genuine home base rather than a place you drop in for a quick question.

Web: run from anywhere

Claude Code on the web lets you run it from a browser and start or check jobs from your phone. That is what makes longer work fit a mobile day: kick it off from wherever you are, review it when you are back at a screen.

It pairs with the cloud-versus-local distinction later in this pillar. The web is how you reach a run that does not need your laptop open, which is most of the recurring ones worth setting up.

Web is the surface that unshackles the work from your machine. You do not need your laptop, your local setup, or even to be at a desk. You open a browser and the same agent and the same session are there. For anyone whose day is a corridor of meetings, this is the surface that turns waiting-room time into progress you actually make.

Your setup travels with you

The quiet feature that makes four surfaces feel like one is that your configuration follows you. The standing brief in CLAUDE.md, the skills you wrote, the MCP servers you connected, the permissions you set, these are not per-surface settings you rebuild in each place. Configure them once and they apply wherever you pick the work up.

This matters more than it sounds. It means you can invest in your setup, spend an afternoon getting the brief and the skills right, and get that investment back on every surface, every day, without redoing it. The setup is the asset, the surface is just where you happen to be standing when you use it.

Switching surfaces mid-task

Because the session is shared, you can hand a job between surfaces without dropping it. Start a long pipeline-cleanup in the terminal at your desk, then close the laptop and check on it from the web on the train. Kick something off from your phone on the way in, then open the desktop app and take over the detailed part when you sit down. The work does not restart, it continues.

The practical pattern is deep work in one surface, checking and unblocking in another. You are not choosing a single surface for a whole project, you are moving to whichever door is closest to where you physically are at each moment, and the agent keeps its place while you move.

A GTM week, surface by surface

Here is what the mix looks like once it is natural. Monday morning I am at my desk in the terminal, running the pipeline-hygiene pass and tuning a skill, deep work with the files right there. Midday I have back-to-back calls, so I start the next enrichment job before the first one and check it from the web between meetings, approving a step from a conference room without opening my laptop. On the walk to lunch I kick off a quick research task from my phone.

By Friday the pattern is obvious: one agent, one continuous body of work, met through whichever door my day put me next to. I never think which surface should I use as a real decision, I just reach for the nearest one and the work is there, mid-thought, where I left it. That is the whole promise of four doors into one room, and it only shows up once you stop treating the surfaces as separate tools and start treating them as entrances.

How a GTM operator should choose

Pick by the moment, not by principle. Building or debugging a repeatable task, use the CLI. Living in it all day next to your CRM, use the desktop app. Working inside a repo of your prompts and skills, use the IDE. Away from your desk and need to start or check a run, use the web.

Because the setup travels, none of these is a lock-in, and trying to pick the one true surface is wasted worry. Use the door nearest the work. That is the whole strategy.

The honest rule is boring: pick the surface closest to where you are and what the task needs. Files in front of you and real focus, the IDE or terminal. Away from your desk and you just need to start or check something, the web or your phone. You will settle into a default, terminal for most, and reach for the others when your location changes. The point of four doors is that you never have to be at a specific one to keep moving.

Where it goes wrong

The main mistake is surface thrash: bouncing between surfaces out of habit rather than need, so you are always switching and never settling into the deep work. The surfaces exist to fit your location, not to be rotated for their own sake. If you are at your desk with the files in front of you, stay in the terminal or IDE and do the work.

The other is treating the web or the phone as the place for heavy lifting. They shine for starting, checking, and approving, the light touches between meetings. The dense, iterative work that needs your full attention still wants a real keyboard and a surface close to the files. Match the weight of the task to the surface, not just your location.

• Surface thrash: switching for its own sake instead of settling into deep work.
• Doing heavy iteration on the phone or web, where a quick check was the right use.
• Rebuilding setup per surface, forgetting that CLAUDE.md, skills, and MCP already travel.

How to set it up

Frequently asked questions

Sources & further reading

• Claude Docs
• Anthropic news

Claude ships fast. This page was last reviewed Aug 22, 2026; verify time-sensitive details against the official docs above before relying on them.