How to use Claude Code on a Mac, from the first request to a reviewed change

Most people who look up how to use Claude Code have already installed it and typed a first request. The tool answered, edited a file or two, and something felt unfinished. It is not clear which of its changes to trust, how to undo the ones that went wrong, or how to hand it a bigger task without losing track of what happened. The documentation covers each feature on its own page. What it covers less is the order in which those features fit together during a normal hour of work.

This guide treats Claude Code as a loop rather than a list of commands. Each pass through the loop has the same shape: choose where the session runs, let it read before it writes, agree on a plan, let it make one change, review that change, then keep it or roll it back. Everything below is taken from the official documentation at code.claude.com as of September 2026. Where behavior depends on a plan or a version, that is stated.

Start the session in the folder the work belongs to

Claude Code works on whatever directory it is started in. In the terminal that means running cd into the project first and then typing claude. The prompt that appears shows the version, the current model and the working directory above it, which is the first thing worth reading: if the directory is wrong, every later answer is about the wrong files.

The folder choice matters more than it looks. The session reads project instructions from a CLAUDE.md file at the root of that folder, and it treats the folder as the boundary of the work. Starting one level too high, in a directory that holds five repositories, gives it more to search and less idea of what the task is. Starting one level too low, inside src, hides the test setup and the package file it needs to run anything.

A few practical rules follow from this.

• Start at the root of one repository, where the .git folder and the package or build file live.
• If a task spans two repositories, start in the main one and add the other with the --add-dir flag rather than starting in their shared parent.
• Keep one terminal tab per project. Claude Code sessions are tied to the directory, and claude -c continues the most recent conversation in the current directory, so a tab per project keeps that command predictable.

The desktop app and the editor extensions ask the same question in a different way. The desktop app's Code tab has a Select folder button before the first message, and the editor extension uses the folder the editor has open. The rule is the same in all of them: the session is only as good as the folder it was pointed at.

Let it read before it writes

The quickstart's first suggested prompts are questions, not tasks: what does this project do, where is the main entry point, explain the folder structure. That order is deliberate. Claude Code reads files as it needs them, so there is no need to paste code into the prompt, but it still forms its picture of the project from whatever it has read so far. A short exploratory exchange at the start gives it the right picture before it touches anything.

This is also where requests become specific. The documentation's own contrast is between "fix the bug" and "fix the login bug where users see a blank screen after entering wrong credentials". The second version names the symptom, the place and the trigger. It removes a round of guessing and it makes the result easy to check, because the success condition is written into the request.

Two habits make this stage cheaper:

• Point at files by name. Typing @ followed by a path pulls that file into the conversation directly. When the relevant file is already known, this saves the search.
• Ask for the test first. A request such as "find the test that covers date parsing and run it" establishes whether a failing case exists before any fix is written. It also gives the later change something objective to pass.

If the exploration turns up something the session keeps getting wrong about the project, such as the build command, a directory convention or a step that must never be skipped, that belongs in CLAUDE.md. The official memory guide puts it plainly: write down what would otherwise be re-explained. Running /init generates a starting version from the codebase, and editing it by hand from there is normal.

Agree on a plan before anything changes

For anything larger than a one line fix, the most useful control in Claude Code is plan mode. In plan mode the session reads and proposes an approach without editing files. Pressing Shift+Tab cycles the permission mode during a session, and the status bar shows which one is active, for example ⏸ plan mode on. A session can also start in it with claude --permission-mode plan.

The value of a plan is that it can be corrected while it is still text. If it proposes rewriting a module when a two line change would do, that is visible before any file moves. If it misreads which component owns a piece of state, the misreading shows up in the plan rather than in a diff spread across six files. Correcting a plan costs one message. Correcting a finished change costs a review and a rollback.

A good plan from Claude Code usually lists the files it intends to change, the order, and how it will verify the result. Reading it with three questions in mind is enough:

1. Are these the right files, and is anything missing?
2. Is there a smaller change that meets the same goal?
3. How will the result be checked, and is that check real?

Once the plan is acceptable, switch out of plan mode and tell it to proceed. For work that genuinely has several stages, it helps to ask for the stages to be done one at a time, with a stop after each. The quickstart suggests the same thing: break a complex task into numbered steps rather than handing over the whole goal in one sentence.

Choose how much it may do without asking

What happens after the plan depends on the permission mode. The documentation lists these, and the differences are worth knowing before handing over a real task.

Mode	What runs without asking	Typical use
Manual (default)	Reading files only	Sensitive work, reviewing every action
Accept edits	Reads, file edits, common filesystem commands	Iterating on code that is being reviewed
Plan	Reads, plus commands the classifier approves when auto mode is available	Exploring before a change
Auto	Everything, with a classifier checking actions	Long tasks, fewer prompts
Bypass permissions	Everything	Isolated containers and virtual machines only

On Pro, Max and Team plans, auto mode is the built-in starting mode for interactive terminal sessions: a second model reviews actions in the background and blocks risky ones instead of asking. On other plans the starting mode is Manual. Settings or an organization policy can change that starting point.

The practical choice is between seeing every step and seeing the result. Manual mode is slower but leaves nothing unseen, which suits the first few sessions in an unfamiliar repository. Accept edits and auto mode move faster, and they shift the review to the end. That is a reasonable trade as long as the end review actually happens, which is the subject of the next section.

Permission rules sit on top of the modes. A deny rule in the project's settings file blocks a tool in every mode, including bypass. That is the right place for anything that must never run in this project, such as a deploy script or a command against a production database. A line in CLAUDE.md asking it not to do something is guidance. A deny rule is enforcement.

Review the change as a diff, not as a summary

When Claude Code finishes a task, it writes a short account of what it did. That account is useful for orientation and not sufficient for review, because it describes intent. The diff describes what actually changed.

In the terminal, the plainest review is Git. Asking what files have I changed? or running git diff directly shows every modification in the working tree, including changes made by shell commands, which matters for reasons covered below. In the desktop app, an indicator such as +12 -1 appears after edits, and clicking it opens a diff view file by file where individual lines can be commented on. Claude reads those comments and revises. The VS Code extension shows inline diffs in the editor.

A review that catches real problems looks at a few specific things:

• Files that were not in the plan. An unexpected file in the diff is the most common sign that the task drifted.
• Deleted tests or loosened assertions. A test that passes because it was weakened has not been fixed.
• New dependencies. A changed lockfile deserves a look even when the code change is small.
• Formatting churn. A formatter run across the whole project can bury a three line fix inside hundreds of unrelated changes. Asking it to limit formatting to touched files keeps diffs readable.

It also helps to review files where they live, not only as patches. Opening the changed folder and looking at what was created, renamed or moved catches things a diff view shows less clearly, such as a new file saved in the wrong directory or a temporary file left behind.

Keep it, or rewind it

Claude Code captures a checkpoint before each prompt that starts a turn. Running /rewind, or pressing Esc twice with an empty prompt, opens a menu listing each prompt in the session. From there it can restore the code, the conversation, or both to that point. Checkpoints are saved with the conversation, so rewinding still works after resuming a session later.

Checkpoints have limits that the documentation states directly, and they decide when to rely on them:

• Changes made by shell commands are not tracked. If Claude Code runs rm, mv or cp through the terminal, rewind cannot undo those.
• Edits by most subagents are not restored. The documentation recommends Git for reverting those.
• Edits made outside the session are not tracked. Changes typed by hand in an editor during the session are not part of the checkpoint.
• Symlinked and hard linked files are skipped on restore, with a warning.

Because of this, checkpoints are best treated as a quick undo for the last few steps of one session, and Git as the real record. The documentation says the same: checkpoints are not a replacement for version control. A simple rhythm works well. Commit before a task starts, let Claude Code work, review the diff, and then either commit with a message describing the change or discard it. Asking it to commit my changes with a descriptive message produces a commit message from the diff, which is worth reading before accepting.

When a task goes wrong halfway, rewinding the conversation as well as the code is often better than arguing with it. The failed attempt stays out of its context, and the original request comes back into the input field to be edited and sent again.

Where the loop slows down

After a few days the loop itself is quick. What slows it down is usually the switching around it: the terminal where the session runs, the editor or diff view where changes are reviewed, and the folder window where files are checked, renamed or opened in other applications. Each switch is small. Across a day of short tasks they add up, and they are also where review steps get skipped.

There are a few ways to shorten this. The desktop app puts a terminal, a file pane and the diff view in one window. The VS Code extension keeps the conversation next to the code. A file manager with a built-in terminal keeps the session and the folder it is working on side by side, which suits people whose work is mostly files rather than code. The comparison of file managers for this kind of work sets out what each approach covers.

What to change first

Pick one repository, start sessions only at its root, and commit before every task so each change can be reviewed as a clean diff. Once that habit holds, move from Manual mode to Accept edits for routine work and keep plan mode for anything that touches more than two files. If switching between the terminal and the folder is where time goes, Atriens puts both in one window on the Mac.