Setting up Claude Code after installing it: permissions, project memory and the starting folder

Installing Claude Code takes one command. Setting it up so it behaves the same way every day takes a little longer, and most of the posts that share a personal Claude Code setup are describing that second part: a set of instructions it reads at the start of every session, a set of rules about what it may do without asking, and a habit about where sessions start. None of it is required. All of it saves repeating the same corrections.

This guide covers those three pieces in the order they pay off on a Mac: the starting folder, project memory, and permissions. It stays with what the documentation at code.claude.com describes as of September 2026, and it leaves out status lines, custom agents and plugins, which are worth adding only once the basics are settled.

Confirm the install before configuring anything

Two commands check that the installation is healthy. claude --version prints a version number followed by "(Claude Code)". claude doctor prints read only diagnostics without starting a session: install health, settings file validation errors, and warnings with suggested fixes. Running it once after installing, and again after editing any settings file, catches mistakes before they show up as odd behavior mid task.

Login happens on the first run of claude. It opens a browser to sign in with a Claude subscription or a Console account. The documentation states that the free claude.ai plan does not include Claude Code, so a Pro, Max, Team or Enterprise plan, or a Console account with prepaid credits, is needed. /login inside a session switches accounts later.

On a Mac, the first run in Apple Terminal also offers a terminal setup prompt. Accepting it enables Option as the Meta key, which some shortcuts need, and turns off the audible bell in that profile. It can be run again at any time with /terminal-setup.

Decide where sessions start

Claude Code has access to the directory it was launched in, and that directory becomes the session's primary working directory. Its project settings and its project memory are read from there. This makes the starting folder the most consequential setup decision, and it is one that nobody writes down.

The rule that works for most projects is start at the repository root, where .git and the build or package file live. Starting in a parent folder that holds several projects gives the session too much to search and no single CLAUDE.md to read. Starting inside a subfolder hides the files it needs to run tests.

When a task needs files outside that folder, there are three ways to extend access without moving the starting point:

• --add-dir <path> when starting the session
• /add-dir during a session
• additionalDirectories in a settings file, for folders that are always needed

Files in added directories follow the same permission rules as the main one. Settings can also block reads outside the working directories entirely with permissions.blockReadsOutsideWorkingDirectories, which is worth considering on a machine with sensitive files in the home folder.

For folders on a Mac that are protected by the system, such as Desktop, Documents and Downloads, background sessions request access separately from the terminal. A read that fails with "Operation not permitted" in one of those folders is a macOS permission, not a Claude Code setting.

Give it project memory with CLAUDE.md

Every session starts with a fresh context. What carries over is written in CLAUDE.md files, which Claude reads at the start of each session. The documentation describes several locations, each with a different reach:

File	Applies to	Shared through
~/.claude/CLAUDE.md	All projects for this user	Not shared
./CLAUDE.md or ./.claude/CLAUDE.md	This project	Version control, with the team
./CLAUDE.local.md	This project, this user only	Not shared; add it to .gitignore
/Library/Application Support/ClaudeCode/CLAUDE.md	Everyone on the machine, set by IT	Managed policy

The fastest way to start is /init in the project. It analyzes the codebase and writes a first version with build commands, test instructions and conventions it finds. If a CLAUDE.md already exists, /init suggests improvements instead of overwriting it.

What belongs in it is narrower than people expect. The documentation's guidance is to write down what would otherwise be re-explained: the same mistake made twice, a correction typed in two sessions, context a new teammate would need. Build and test commands, directory conventions and "always do this" rules fit. Multi step procedures, or rules that apply only to one part of the codebase, are better as skills or path scoped rules in .claude/rules/.

Size matters. The documentation recommends keeping each file under 200 lines, because the file is loaded into context every session and longer files reduce adherence. Instructions should be concrete enough to verify: "run npm test before committing" rather than "test your changes". Running /context in a session shows under Memory files which ones actually loaded.

One distinction is worth holding onto. CLAUDE.md is guidance: Claude treats it as context, not as enforced configuration. A line saying "never deploy" makes deploying unlikely. A permission rule makes it impossible. That is the next section.

Claude Code also keeps an auto memory, notes it writes itself from corrections, stored per repository and loaded at the start of sessions. It needs no setup, but it is worth reviewing occasionally so an outdated note does not keep steering sessions.

Set permission rules and a starting mode

Permissions are where setup has the most effect on daily use. Without rules, Claude Code asks before actions depending on the mode; with a few rules in place, routine commands run without interruption and dangerous ones cannot run at all.

Rules live in settings files, which also have scopes:

• ~/.claude/settings.json for the user across all projects
• .claude/settings.json in the project, committed so the team shares it
• .claude/settings.local.json in the project for personal overrides, which Claude Code keeps out of Git when it creates the file

Each rule is an allow, ask or deny entry naming a tool and, optionally, a pattern. The documentation's own example allows Bash(npm run lint) and Bash(npm run test *) and denies Read(./.env) and Read(./.env.*). Rules are evaluated deny first, then ask, then allow, and a deny at any scope cannot be overridden by an allow at another. That makes deny rules the right tool for things that must never happen: reading secrets, running deploy scripts, touching production credentials. The documentation states that permission rules are enforced by Claude Code itself, not by the model.

Settings files are strict JSON. A trailing comma or a comment is a syntax error, reported as a Settings Error at the next start. claude doctor and /status confirm which files loaded.

The starting permission mode can also be set with defaultMode. On Pro, Max and Team plans, interactive terminal sessions start in auto mode by default, where a classifier reviews actions instead of prompting. On other plans the default is Manual. Some people set Manual as the default for the first weeks in a new repository and switch per session with Shift+Tab once they trust the rules.

A useful approach is to let rules grow from use. Approving a command with "Yes, and don't ask again" writes a standing allow rule into .claude/settings.local.json. After a week, reading that file shows which commands were approved often enough to promote into the shared project settings, and which should not have been approved at all.

Settings that help on a Mac

A few settings are specific to working on a Mac, and they are quick to set once.

Notifications. Desktop notifications are sent by default only in Ghostty, Kitty and iTerm2. In Apple Terminal, setting "preferredNotifChannel": "terminal_bell" in ~/.claude/settings.json gives an audible alert when a session finishes or waits for approval.

Updates. The native installer updates in the background. A Homebrew install does not, and needs brew upgrade claude-code from time to time. Knowing which one is installed avoids running an old version without noticing.

Environment variables. Variables that sessions need can go in the env block of a settings file, which applies to terminal and desktop sessions alike. This matters because the desktop app, launched from the Dock, does not pick up every variable exported in ~/.zshrc.

One window for the folder and the session. Setup is also about the workspace around the tool. A terminal on its own does not show the folder a session is changing. Keeping the project's folder visible next to the session, whether in a split terminal with a file listing, the desktop app's panes, or a file manager with a built-in terminal, makes it easier to notice when a session writes somewhere unexpected. The features page shows one way of arranging that, and the pricing page covers what it costs.

Keeping the setup from drifting

A setup that works in the first week tends to drift. Rules get approved in a hurry, CLAUDE.md collects notes that were true for one task, and the personal and shared files start to disagree. A short review every few weeks keeps it useful.

Read the local settings file. .claude/settings.local.json is where standing approvals accumulate. Anything that appears there repeatedly and is safe for everyone belongs in the shared .claude/settings.json. Anything that looks too broad, such as an allow rule for an entire tool rather than one command, is worth narrowing.

Prune CLAUDE.md. The documentation warns that contradictory rules lead Claude to pick one arbitrarily. Reading the file end to end and removing anything outdated or duplicated keeps it under the recommended length and keeps each instruction meaningful. Imports with the @path syntax can move long reference material out of the main file, though imported files still load at the start of every session.

Check what loads. In a monorepo, CLAUDE.md files from other teams' folders can load into a session. The claudeMdExcludes setting skips the ones that do not apply.

Recheck after updates. Claude Code updates often. Reading the release notes, or running claude doctor after an update, confirms that the setup still does what it was meant to.

A setup checklist for a new project

For each new repository, the same short sequence covers most of what matters:

1. Start claude at the repository root and confirm the directory shown above the prompt.
2. Run /init, then edit the result down to what is specific and verifiable.
3. Add deny rules for secrets and anything that touches production in .claude/settings.json.
4. Add allow rules for the lint, test and build commands the project uses.
5. Commit CLAUDE.md and .claude/settings.json so the setup travels with the repository.
6. Run claude doctor and /context to confirm everything loaded.

What to change first

If only one thing gets done today, add deny rules for secrets and production commands to the project's settings file, since that is the only part of setup that is enforced rather than suggested. Then run /init and trim the result. To keep the session and the project folder in view together while it works, Atriens puts both in one window on the Mac.