Claude Code Best Practices 2026: What Anthropic Recommends

Last Updated: November 9, 2026

Summary: The Claude Code best practices Anthropic recommends in November 2026 come down to three moves: tell Claude what it cannot see in your code, give it a check it can run that returns pass or fail, and enforce the few rules that can never be broken with hooks, deny rules or managed settings instead of prompts. Keep CLAUDE.md short (Anthropic's memory guide suggests under 200 lines), use /clear between unrelated tasks, and put a person in charge of approving anything you cannot undo.

Most "Claude Code best practices" lists still repeat 2025-era advice: shout IMPORTANT in your instructions, type "think harder," and guard the context window at all costs. Anthropic's own Claude Code best practices page now says several of those habits are no longer needed, because current models follow plain instructions and run with a 1M-token window on most models.

This guide turns that official page into a plan a business or engineering lead can act on. It sorts every practice by who enforces it, lists what your team can stop doing, and ends with a checklist for letting Claude Code run without supervision. Everything below was checked against Anthropic's documentation on November 9, 2026.

Anthropic's 2026 Claude Code best practices are about adding the project knowledge, checks and hard limits that Claude cannot work out from your repository on its own. The documentation opens by saying that "in most cases, your first plain prompt in a fresh session already does the right thing, without any setup on your part."

That is a change in tone from earlier guidance. According to Anthropic, new terminal and VS Code sessions now start in auto mode, where a separate classifier model reviews risky actions before they run. Claude also delegates work to subagents on its own and compacts the conversation automatically before the context window fills.

So the best practices are about the gaps the defaults cannot cover. Anthropic lists four typical ones: a deploy process that lives in someone's head, a file that must never be read, a check that has to pass before work counts as done, and a budget you need to stay under.

When a session goes wrong, the documentation says it is almost always one of four problems:

The rest of this guide takes those four problems in order, then covers unattended runs.

In Claude Code, a guideline is an instruction the model reads and may decide not to follow, while a rule is configuration the Claude Code harness must apply every time. Anthropic calls these non-deterministic and deterministic instructions, and choosing the right one is the most useful decision a team lead makes.

Prompts, CLAUDE.md files and skills are non-deterministic. The documentation says current models usually follow them and are "good at understanding your intent," but there is "no guarantee." Hooks, deny rules and managed settings are deterministic: "Claude Code applies this every time, no matter what the model decided to do."

Anthropic's advice is to let Claude decide most of the time, because "almost every guideline has exceptions" and the model, with the code in front of it, is usually better placed to judge. Reserve the enforced kind for project-specific absolutes, such as never editing a generated folder or always running a license-header script.

The table below sorts the main controls by type, based on the comparison table in Anthropic's documentation, with our notes on who in a company typically owns each one.

A practical signal from the documentation: if you keep adding emphasis to a CLAUDE.md line and Claude still misses it, the line belongs in a hook. The reverse also holds. If you have hooks for things that are only preferences, delete them.

A good CLAUDE.md file is short and holds only what Claude cannot learn by reading the code. Claude Code loads the file into every session, so Anthropic notes that every line "takes a little of Claude's attention on every task, whether it's relevant or not."

Anthropic gives a two-question test before writing anything down: could Claude find this by reading the code, and would it actually go and look? If both answers are yes, leave it out. That rules out the old habit of describing your architecture and file layout, which the documentation now lists under advice you can drop.

According to the official page, the lines that earn a place in CLAUDE.md are:

You do not have to start from a blank page. The /init command generates a first version from your codebase, and the work from there "is mostly removing lines." Anthropic's memory guide recommends staying under 200 lines. The /doctor command suggests cuts, and /doctor prompt-audit flags instructions written for older models, pointing at missing files, or contradicting each other.

Three related habits keep the file lean. Personal preferences go in CLAUDE.local.md, added to .gitignore. Rules that only matter in one folder go in .claude/rules/ with a paths: filter, so they load only when Claude works there. Longer team procedures, such as a release runbook, go in a skill at .claude/skills/<name>/SKILL.md, which Claude reads in full only when a task calls for it.

Better Claude Code prompts name the file, describe the symptom and say what "fixed" looks like, because that is information Claude cannot get from the code. Anthropic's example swaps "fix the login bug" for a prompt that says login fails after a session timeout, points to token refresh in src/auth/, and asks for a failing test before the fix.

Hand over what you already have instead of describing it. The documentation recommends typing @ and a path to include a file, pasting a screenshot of a design or error, or piping command output into Claude from your shell.

Two wording points stand out in the 2026 guidance. First, phrases like "think step by step" or "be thorough" are "ordinary prompt text rather than keywords." The main control for reasoning depth is the effort level, set with /effort. Second, one phrase still helps: "be ambitious." Anthropic says Claude tends to build the smallest thing that satisfies a request, so asking for ambition tells it about scope, which only you know.

When you are not sure what you want yet, ask Claude to interview you. Anthropic's example has Claude ask multiple-choice questions until it can write a spec to SPEC.md, then start a fresh session to build from that file. The spec doubles as the reference for review later.

The surest way to know Claude Code's work is done is to give it something it can run that returns pass or fail, such as a test file, a build's exit code, a linter or a script that compares output to a fixture. Without that, Anthropic says, "that makes you the test suite," and every mistake waits until you happen to notice it.

The documentation describes four levels of strictness, from lightest to strongest:

Whichever level you choose, ask for evidence: the command Claude ran and its output, or a screenshot. Anthropic puts it bluntly: "All tests pass" on its own "tells you very little." For a session nobody watched, the output is the only evidence you have.

One caution from the documentation is worth repeating to any team. When you ask a reviewer to find problems, tell it to skip style, because "a reviewer that's asked to find problems will always find something," and fixing every finding leads to extra layers and tests for cases that cannot happen.

Sameer's take: The biggest business mistake with AI is trusting its output without checking it.

To stop Claude Code from breaking a rule that has zero exceptions, move it out of CLAUDE.md and into a hook, a permission deny rule or a managed setting. Anthropic's tip is direct: "CLAUDE.md is for guidelines, and Claude is allowed to decide a guideline doesn't apply."

Hooks run your own command at fixed points in Claude's loop, for example after every edit or before a tool call. Anthropic's examples include a PostToolUse hook that runs a formatter after every Edit or Write, and a PreToolUse hook that blocks edits to a migrations folder. For real enforcement, the documentation says to use a command or http hook rather than a prompt or agent hook, which asks another model to decide.

Permission rules decide what Claude may run, read and fetch. The documentation stresses that deny rules hold in every permission mode, including auto mode and bypassPermissions, which is why rules like "never read .env" belong there. It also flags the edges: a Read deny rule catches common commands like cat .env, but not a script that opens the file.

The sandbox, turned on with /sandbox, adds an operating-system limit on file and network access for shell commands on macOS, Linux and WSL2. For anything security-related, Anthropic says you want both permission rules and the sandbox.

Where a rule lives decides who it applies to. Personal settings files apply to one person, .claude/settings.json applies to everyone who works in the repo once committed, and managed settings apply to the whole organization and cannot be overridden by any personal file. That makes managed settings the place for a security team's policy.

Keep the enforced set small. Anthropic warns that every hook and deny rule will sometimes fire when it should not, and "if you ever find yourself at forty of them, most are probably preferences."

Run /usage first to see where time and tokens went, then use /clear between unrelated tasks, because every request resends the whole conversation. Anthropic says /clear "costs nothing," while a session that has collected three unrelated tasks re-reads all three on every turn of the fourth.

The documentation lists the defaults a new session makes for you: auto mode in interactive terminal and VS Code sessions, the default model at medium effort on most plans, subagent delegation and automatic compaction. When a task costs more than it should, one of those four is usually why. The main levers are:

Caching also affects cost. According to the documentation, the prompt cache lasts about an hour on a subscription and five minutes on an API key, cloud provider or usage credits. If your developers use Claude Code through paid plans, our guide to Claude usage limits explains what each plan allows, and our Claude API pricing breakdown covers per-token costs for API-key users.

Anthropic now says several popular Claude Code tips are unnecessary, including aggressive context management, ALL CAPS instructions, and "think harder" phrases. The documentation explains that most were workarounds "for something the model couldn't reliably do yet, and the models have since caught up."

For teams that wrote internal Claude Code playbooks in 2025, this table is a quick audit list. Anything on the left that still sits in a shared CLAUDE.md file is costing attention on every task.

Before Claude Code runs unattended, make sure it knows what done looks like, can check its own work, can only touch what it should, has a cap on turns or spend, and hands its result to a person for sign-off. Anthropic frames these as five questions to ask about each specific task.

For scripts and CI jobs, claude -p "prompt" runs once and exits. The documentation recommends --bare so the run skips local hooks, skills, plugins, MCP servers and CLAUDE.md files and behaves the same wherever it runs, plus --allowedTools with --permission-mode dontAsk to refuse anything not pre-approved. Anthropic's advice is to try a batch on three files first, fix the prompt, then run the rest.

For recurring work, /loop repeats a prompt inside an open session, while /schedule sets up a cloud scheduled task that runs when your laptop is closed. Anthropic warns that before you leave a cloud scheduled task running, you should protect main with a GitHub branch rule the task cannot bypass, and watch the first few runs.

For parallel work, claude -w starts a session in its own git worktree so edits cannot collide. A second session also makes an easy independent reviewer: one session writes the code, another reviews it without having watched it being written. If your team connects outside systems, our guide to the Claude MCP server setup covers that side, and Claude Code skills explains how to package team procedures.

What is the most important Claude Code best practice?
Give Claude a check it can run that returns pass or fail, such as a test file, a build or a linter. Anthropic says this lets Claude fix its own mistakes instead of making you the test suite.

How long should a CLAUDE.md file be?
Short. Anthropic's memory guide recommends staying under 200 lines, and the best practices page says the file should only hold what Claude cannot work out from the code, such as test commands, misleading code and team decisions.

Does typing think harder still work in Claude Code?
Not as a control. Anthropic says phrases like think hard and be thorough are ordinary prompt text, and effort level, set with /effort, is the main control for how long Claude thinks. The word ultrathink still requests deeper reasoning for a single turn.

How do I stop Claude Code from reading secret files?
Add deny rules such as Read(./.env) to your permission settings. Anthropic says deny rules hold in every permission mode, including auto mode, and recommends turning on the sandbox as well for anything security-related.

When should I use /clear in Claude Code?
Use /clear between unrelated tasks and after two failed corrections. Anthropic says it costs nothing and stops the next task from paying for the previous one's history, since every request resends the whole conversation.

The 2026 Claude Code best practices are shorter than the lists that rank for them. Anthropic's own guidance says the defaults now handle most sessions, so your job is to fill three gaps: tell Claude what is not in the repo, give it a pass-or-fail check, and enforce the handful of true rules with hooks, deny rules or managed settings.

For a business, the governance point matters most. Keep CLAUDE.md short and shared, keep enforced rules few and owned, cap spend on unattended runs, and make sure a person approves every merge or deploy. If you are still deciding which coding tool to standardize on, our Claude Code vs Cursor comparison is a good next read.

⭐ Get more AI Business Weekly in Google: add us as a preferred source on Google.

Written by Sameer Khan with AI assistance, fact-checked against the sources linked above.