What is the Claude Code CLI?

The Claude Code CLI is the command you run when you want Claude to do work instead of chat. It is Anthropic's official tool, maintained alongside the rest of the Claude product surface. You install it once with npm install -g @anthropic-ai/claude-code, then anywhere you have a project you type claude and a coding agent opens in your terminal. It reads your files. It writes your files. It runs your shell commands. It fetches URLs. It connects to MCP servers. It speaks your stack, whatever your stack is, because it works with the real tools that already live on your machine instead of trying to emulate them in a sandbox.

If you have only used Claude in a browser tab, the CLI feels like a different product. The model is the same. The difference is the harness around it. In a browser you copy and paste, you describe code, you read suggestions and then you go implement them yourself. In the CLI Claude acts. The same model, with hands.

Why it exists

A chat window is a great place to think. It is a terrible place to ship. Every real engineering task requires reading files you did not type into the chat, running commands you cannot run from a browser, and producing outputs that live as files, commits, and pull requests. The CLI closes that gap. It puts Claude inside the environment where the work actually happens, with the same permissions you have, on the same files you can already see.

It also gives Anthropic a place to push agentic capabilities forward, like skills, subagents, and MCP, in a way that would not fit in a generic chatbox. The CLI is where Anthropic ships the experimental edge of how AI assistants are supposed to work, and that means it tends to get powerful features first.

What it can do out of the box

• Read and write files in your project with explicit confirmation on edits by default.
• Run shell commands you approve, including tests, builds, type-checks, linters, and git operations.
• Fetch URLs and read the content as context, useful for pulling docs, error pages, or external API references.
• Spawn subagents for parallel work when a task naturally splits into independent pieces.
• Load Claude Skills from .claude/skills automatically when their descriptions match the task.
• Connect to any MCP servers configured in your settings so Claude can reach databases, APIs, and other systems.
• Honor a CLAUDE.md at the project root as persistent project context that loads every session.
• Stream tool calls and edits so you can stop or redirect mid-flight if you do not like where things are going.

That set of capabilities is enough to handle the bulk of normal development. Most of what makes the CLI feel powerful is not exotic. It is that every tool is real, every action affects real files, and the loop continues until the work is done. The boring part is what makes it good.

How it actually works

The CLI is a harness around the Claude API. When you start a session it reads your CLAUDE.md, scans available skills, and connects to any configured MCP servers. As you type, your message goes to Claude along with the available tool definitions. Claude responds with either text for you or a tool call. The CLI runs the tool, returns the result to Claude, and the loop continues until Claude finishes or asks you a question. Each turn is a transparent step you can read after the fact.

The model itself is from the Claude family: Sonnet for most work and Opus when you want maximum capability on the toughest reasoning. The CLI handles routing, retries, streaming, and the safety prompts that confirm risky actions before they run. It also tracks usage so you can see what a session cost when you are on API billing.

Configuration is straightforward. A single settings file controls which MCP servers to start, which models to prefer, which directories Claude can see, and which kinds of actions require explicit approval. You can override on a per-project basis. The defaults are sane, and you only touch the config when you actually need to.

Common misconceptions

It is not a VS Code plugin, though it pairs well with one. It is a terminal program. It runs wherever you have a shell. That is part of why it is so flexible: it does not care which editor you use, only which directory you are in. You can keep your existing editor setup unchanged and add the CLI alongside it.

It is not a different model from the Claude you already use. It is the same model family with a real harness. People sometimes assume the CLI is 'smarter' than chat. It is not smarter. It is more capable because it can actually act on the world instead of describing what it would do.

It is also not a runaway autonomous agent by default. The CLI asks before doing anything destructive. You can loosen that with explicit settings if you want, but the standard experience is supervised and the prompts are short enough that you do not feel like you are babysitting it.

How to get started

1. 1Make sure Node.js 18 or later is installed on your machine.
2. 2Run npm install -g @anthropic-ai/claude-code to install the CLI globally so the claude command is available anywhere.
3. 3Sign in with your Anthropic account or set up API access, depending on which billing path you use.
4. 4cd into a real project, not a scratch folder. Pick something you actually want to move forward this week.
5. 5Add a CLAUDE.md at the root with one paragraph of project context: stack, conventions, and what you care about.
6. 6Run claude and start with a clear goal. Watch the tool calls. Approve, redirect, or stop as needed.
7. 7After your first session, jot down anything you wish Claude had known and add it to CLAUDE.md or to a new skill.

The first session feels strange because you are not used to handing the typing to someone else. The second session feels natural. By the fifth session, you are restructuring how you plan work and writing better goals on the first try.

When not to reach for the CLI

For quick brainstorming or rubber-ducking, the browser chat is fine and faster to open. For one-line tweaks in a file you already have open, just type it. The CLI shines on multi-file work, repeatable workflows, anything where the goal is a finished artifact instead of a thought. Reaching for it on a one-line task is like booting a forklift to move a coffee cup.

Avoid running it against an unfamiliar codebase with broad write permissions and a vague goal. That is the recipe for a confusing diff. Give it a tight goal, a clean working tree, and read the diff before you commit. The CLI is a tool for builders who are still in the loop, not a magic wand for code you do not understand.

Permissions and the trust gradient

The CLI ships with a sensible permissions model out of the box, but the right shape for your project depends on what you trust the agent to do. New projects should run with confirmations on every shell command and file write. Once you have a feel for how Claude works in your codebase, you can loosen confirmations on safe categories, like running tests or formatting code, while keeping them on for anything that touches infrastructure, secrets, or production. The slider between supervision and autonomy is yours to set.

The thing to avoid is granting blanket trust on day one. People who do that report the early stories about agents going off the rails, which is almost always a config problem rather than a model problem. A few sessions of careful supervision teaches you which actions are routine and which deserve a human in the loop, and your settings can encode that lesson permanently.

Once you have the trust gradient tuned, sessions feel quiet. Routine work happens without interruption. Risky work pauses for your nod. That rhythm is what people mean when they say Claude Code feels collaborative rather than automated. It is not a magic word, it is a permissions setting that you have grown into.

Slash commands and the day-to-day feel

Inside a session, the CLI has a small set of slash commands worth knowing. The /help command lists what is available. The /mcp command shows connected MCP servers and the tools each one offers. The /clear command starts a fresh context if the current one has wandered. The /compact command summarizes the session so far when you want to keep going without burning context on history you no longer need. None of these are exotic, but knowing them turns the CLI from a black box into a tool you can operate fluently.

Day-to-day, most sessions are a goal, a few rounds of edits, a test run, and a commit. The CLI fades into the background once you have a rhythm. That fading is the goal. A tool you stop noticing is a tool that has earned a permanent spot in your workflow, and the CLI gets there within a couple of weeks for most builders who give it a real shot.

Custom slash commands are worth setting up too. The CLI lets you define your own commands as Markdown files in a commands directory. Each one is a saved prompt with optional arguments. Use them for the briefings you find yourself typing more than once: a deploy check, a release-notes draft, a new-feature scaffold. A small set of custom commands makes your sessions feel personal and shaves real minutes off the same tasks you would otherwise re-explain.

How the CLI fits the broader ecosystem

The CLI is the home base for everything else Claude Code offers. CLAUDE.md gives it persistent project context. Skills give it on-demand playbooks. MCP servers give it external tools. Subagents let it parallelize when work splits naturally. Together they form the Claude Code workflow that members at claudecodeclub.ai use to ship real products solo. The $9/mo membership exists to shortcut the trial and error of putting those pieces together, with working templates and walkthroughs. The CLI is where the workflow runs every day, and the rest of the ecosystem only matters because it has a real harness to plug into.

If you are evaluating Claude Code for the first time, the test is not whether the CLI is impressive in a demo. The test is whether you actually use it on the third Monday after you installed it. If the answer is yes, you have found the workflow. If the answer is no, your goals were probably too vague or your project too small. Pick a real task and try again with a clearer brief. The CLI rewards the second attempt.