How to use Claude Code on a Mac: the first session, start to finish

Searching for how to use Claude Code usually happens at one of two moments. Either nothing is installed yet and the question is what the first hour looks like, or it has been installed for a week, it works, and it still feels like typing into a box and hoping. Both have the same answer underneath: the tool is a command line program that reads a project as needed, and almost everything that separates a frustrating session from a useful one comes down to three decisions. Which install method, which permission mode, and what gets written down so it does not have to be said again tomorrow.

What has to be true before the first command

The requirements are short and worth checking, because a mismatch here shows up later as an error that looks like something else.

macOS 13.0 or later, 4 GB or more of RAM, and an x64 or ARM64 processor. An internet connection is required; this is not a local model. Any of bash, zsh, PowerShell, or CMD works as the shell, which on a current Mac means the default zsh is fine with no changes. Availability is limited to the countries Anthropic supports.

An account is also required, and the accepted kinds are worth knowing before paying for anything. A Claude subscription on the Pro, Max, Team, or Enterprise plan is the recommended route. A Claude Console account with prepaid credits works and bills by usage; on first login it creates a workspace named for Claude Code so costs are tracked in one place. Access through Amazon Bedrock, Google Cloud's Agent Platform, or Microsoft Foundry covers organisations that route model traffic through their own cloud. A self hosted Claude apps gateway is the fourth case, where an administrator has already set the URL and login goes through corporate single sign on.

One dependency is usually invisible: ripgrep ships with Claude Code and is what search runs on. If searching inside the session fails while everything else works, that is the thing to look at rather than the model.

Picking an install method, and why the choice matters later

There are two reasonable routes on a Mac and they differ in exactly one respect that people discover a month in.

The native installer:

curl -fsSL https://claude.ai/install.sh | bash

Native installations update themselves in the background, which keeps a session on the current version without anyone remembering to do anything.

The Homebrew route, for a machine where everything else already comes from Homebrew:

brew install --cask claude-code

Homebrew installations do not auto update. There are also two casks rather than one. The claude-code cask follows the stable channel, which runs roughly a week behind and skips releases with major regressions. The claude-code@latest cask takes new versions as soon as they ship. Whichever gets installed, brew upgrade claude-code or brew upgrade claude-code@latest has to be run by hand to pick up features and security fixes.

The trade is straightforward. The native install trades control for currency; the stable Homebrew cask trades currency for a week of other people finding the regressions first. For a machine that runs client work, the stable cask plus a weekly upgrade is defensible. For a machine used to keep up with the tool, the native install removes a chore.

Confirm either one the same way:

claude --version

A working installation prints a version number followed by the product name in parentheses. If the shell reports that the command is not found, the install directory is not on PATH yet, and that is a path problem rather than an installation problem.

The first session, in the order it actually happens

Start it from inside the project, not from the home directory. The working directory is the context, and starting in the wrong place is the most common reason a first session feels blind.

cd /path/to/your/project
claude

The first run prompts for login in a browser. Setting ANTHROPIC_API_KEY in the environment skips that prompt and asks for approval of the key instead, which is the shape most continuous integration setups use. Inside a running session, /login switches accounts or re authenticates. Credentials persist afterward, so this happens once.

The prompt that appears shows the version, the current model, and the working directory above it. Reading those three every time is a cheap habit: a session pointed at the wrong directory or running a different model than expected explains a surprising share of confusing answers.

Then ask something that requires reading rather than writing. What the project does, what it is built with, where the entry point is, how the folders are arranged. Files get read as needed, so nothing has to be attached or pasted. This first step is not a warm up. It is how the session builds enough context that the next instruction lands in the right file.

Only after that, a small change. Adding one function, fixing one obvious bug. The change gets shown before or after it is applied depending on the permission mode, which is the next thing to understand.

Permission modes are the setting that decides how the session feels

This is the single control that most changes the experience, and it is set differently depending on the plan.

Auto mode is the starting permission mode for interactive terminal sessions on the Pro, Max, and Team plans. In auto mode a classifier reviews proposed actions instead of a person, and most file edits and most commands run without a prompt. On other plans, Manual mode is the starting point, and approval is requested per action. Organisation settings or local settings can change which mode a session starts in.

Shift+Tab cycles the permission mode of the running session at any time. That is the escape hatch in both directions: down to manual while touching something delicate, up to auto while doing bulk work on a branch that is easy to throw away.

The thing to understand about all of this is that instructions are context, not enforcement. A rule written in a file is something the model reads and generally follows. It is not a wall. To actually block an action regardless of what the model decides, the mechanism is a PreToolUse hook, which runs outside the model's judgement. Anyone whose reason for hesitating is a command that must never run on a particular machine should be reaching for a hook rather than a strongly worded instruction.

Writing down what would otherwise be repeated tomorrow

The difference between week one and month three is almost entirely this. Two mechanisms carry knowledge between sessions, and both load at the start of every conversation.

CLAUDE.md files are written by hand and hold instructions: build commands, conventions, project layout, rules that always apply. A repository that already uses AGENTS.md can be read from that file instead, or alongside. Locations, from broadest to most specific:

Scope	Location on a Mac	What belongs there
Managed policy	/Library/Application Support/ClaudeCode/CLAUDE.md	Organisation wide standards, set by IT
User	~/.claude/CLAUDE.md	Personal preferences across all projects
Project	./CLAUDE.md or ./.claude/CLAUDE.md	Team rules, shared through source control
Local	./CLAUDE.local.md	Personal project notes, kept out of Git

Files in the directory hierarchy above the working directory load at launch. Files in subdirectories load on demand when something in that directory is read. Running /context inside a session confirms what actually got loaded, which is the fastest way to settle an argument about whether a rule is being seen at all.

Auto memory is the other half, and it is written by the model rather than by a person. It collects corrections and preferences per repository, shared across worktrees, and the first 200 lines or 25 KB of it load into every session. That cap is the reason an index that grows without pruning quietly stops being read.

The rule of thumb for what belongs in CLAUDE.md: add an entry the second time the same correction gets typed, or the second time a review catches something the tool should have known about this codebase. Multi step procedures and rules that only matter in one corner of the tree belong in a skill or a path scoped rule instead, because a file that holds everything gets followed less consistently than a short one.

The commands that cover most days

Shell commands start or resume a session. Session commands run inside one.

Command	What it does
claude	Start an interactive session
claude "task"	Start interactive with an opening instruction
claude -p "query"	Run one query and exit, for scripts and pipes
claude -c	Continue the most recent conversation in this directory
claude -r	Pick a previous conversation to resume
/clear	Drop the conversation history and start clean
/help	List available commands
/exit	Leave the session

Four keys carry more weight than the list suggests. Typing / lists the commands and skills available right now. Tab completes them. The up arrow walks command history. Shift+Tab cycles permission modes. The habit worth building is /clear between unrelated tasks, because a session carrying an abandoned approach argues with the new instruction.

Where the terminal stops being the right window

Claude Code is a terminal program, and the terminal is an excellent place to run it and a poor place to see what it did. The session prints a diff; it does not show a folder. A run that renamed forty files, wrote three, and left one half finished is legible in a file window and tedious in scrollback.

This is why the same work often ends up spread across three windows: a file window to see the result, a terminal to run the session, and an editor to read what changed. None of those windows knows what the other two are looking at, and the cost is paid in switching rather than in any single slow step. A file manager that holds a directory listing and a terminal in the same window removes that specific trip, and what such a window covers is worth checking against the three applications currently open.

The other gap is time, not space. An agent that stops to ask a question keeps the desk occupied until someone comes back to it. Answering that question from a phone turns a blocked half hour into a thirty second reply, and continuing from an iPhone or iPad is the part of the setup most people leave until after they have lost an afternoon to it.

What to change first

Install it with whichever route matches how the machine is maintained, start the first session inside a real project, and spend the first ten minutes asking questions rather than requesting changes. Then write the three project facts that would otherwise be retyped tomorrow into a project CLAUDE.md, and check with /context that they loaded. If the friction that remains is seeing what happened rather than making it happen, that is a window problem, and Atriens is aimed at it.