Claude Code best practices, now that you're out of the loop

Key ideas

• Every job you stop doing by hand in a session has to be picked up by the model, the harness or the environment.
• Your instructions file should hold only what Claude can't see in the code. Shouted reminders written for older models now make results worse.
• Auto mode is better than people at catching dangerous commands, but it isn't a guarantee. A deny rule is.
• Write a hard rule for anything you can't take back, and leave the rest to the model.
• A permission decides whether a command runs. Only a sandbox or a separate machine limits what it can reach once it's running.
• Give Claude checks that come back pass or fail, and review those instead of reading every change at the end.

The jobs you used to do by hand in a Claude Code session haven’t gone away. They’ve moved to the model, the harness (Claude Code’s own rules and scripts) and the environment the session runs in. That’s Lydia Hallie’s argument in this 18-minute talk, and it comes with a short test for what to keep: write a hard rule for anything you can’t take back, and leave the rest to the model. These are my notes, in the order she builds the setup: shorter instructions, auto mode, deny rules, a sandbox or a cloud machine, checks that pass or fail, and one session that starts the others. I’ve checked her figures and feature names against Anthropic’s own pages.

Who does each job now

Hallie starts from the way sessions looked early in 2026: one or two at a time, a person approving each command, and an instructions file full of reminders. At Anthropic now, she says, people run dozens of sessions for hours at a time, and some sessions start other sessions. Anthropic’s own post on its source control gives the scale: about 2,500 code changes merged a day in May 2026 and over 30,000 a day by September.

Her summary at the end is a map of where each old job went.

What’s left for the person, in her telling, is starting the first session and reviewing what comes out.

Instructions

Older advice had you fill the instructions file (CLAUDE.md) with capital-letter warnings and never-do-this lines. Hallie says today’s models don’t need them, and that they can send the model off track, with more tool calls and worse results.

Her rule is to keep only what Claude can’t see from the code. Her example is a service that still depends on a legacy source nothing in the code points to. What stack you’re on and where to look can go.

The command for the clean-up is /doctor prompt-audit. It checks your CLAUDE.md files, skills and other settings for instructions that are outdated or contradict each other. Hallie describes it as finding what the new model no longer needs. The docs say it needs Claude Code 2.1.283 or later.

Auto mode

In auto mode a separate classifier model reviews each action before it runs. Reads and file edits inside your project skip the review. Commands it judges safe, such as running tests or installing dependencies, go through, and anything it’s unsure of is blocked. Hallie says Anthropic started making it the default in August 2026.

By default the classifier trusts your working folder and the repository’s remotes as they were when the session started. Everything else counts as external, so her example of pushing to a separate deploy repository gets blocked and you’re asked again. If you’re still approving a lot, she says to look at settings first: you can describe the repositories, buckets and domains you trust in plain English, and that text goes to the classifier. The setting is autoMode.environment.

Deny rules

Auto mode is a model making a judgment, so it isn’t a guarantee. Hallie cites Anthropic’s August study: people approving by hand caught about 14% of the clearly dangerous commands planted in a test environment, and auto mode blocked 89%. I read those figures in press coverage of Anthropic’s August 7 announcement, not on a study page. That still leaves about one in ten getting through.

For a guarantee you need a deny rule. Claude Code checks deny rules before the classifier, and a call that matches one never reaches it. They block in every permission mode.

Her test for what deserves one: if Claude gets this wrong once, can I take it back? Wrong code can be reverted, so that stays with the model. Throwing away uncommitted changes, or reading a key that then sits in the transcript, can’t be undone, so those get rules. Her worked example is a deny rule on reading the .env file, which auto mode would otherwise allow.

Sandbox and cloud sessions

A permission only decides whether a tool call runs. It can’t limit what the command reaches once it’s running. Her example is npm test: an ordinary command, but it runs code you didn’t write, and a compromised dependency could open the same .env file or your SSH keys and send them somewhere. A person approving by hand would have clicked allow too, because there’s nothing in the command to object to.

The sandbox closes that gap on your own machine. The operating system enforces which files a command can read, where it can write and which hosts it can reach, and the same limits apply to every process the command starts. With it on, she says, the .env deny rule is passed down to the operating system, so the dependency can’t open the file either.

Two limits from the docs, which she also names:

• A sandboxed command can still read most of the machine by default, including ~/.ssh, so add a rule for your keys.
• The sandbox covers shell commands only. Claude’s own file tools, MCP servers and hooks run outside it.

A cloud session removes the problem instead of fencing it. The session gets its own virtual machine with a fresh copy of the repository, so files that aren’t in git, such as .env, SSH keys and your GitHub token, aren’t there at all. It also keeps running with the laptop closed. Network access starts limited, to places like package registries and GitHub, and you add other domains to the environment yourself. An API key goes in as a network secret, which is attached to matching requests outside the machine, so the model never sees its value.

The machine is disposable, but a pushed commit or a message sent through a connector isn’t. So she still runs cloud sessions in auto mode, with the deny rules committed to the repository so they come along.

Verification

When you approved every step you’d seen every change. With sessions running for hours, you haven’t, and you won’t read every file at the end. Her example is asking Claude to move login to a new API: one run might leave the old API in place, another might move only new logins, and another might log everyone out. Each of those is a reasonable reading of the prompt.

The fix is checkpoints that come back pass or fail: a test, a build, a screenshot. You review those, which is much shorter than reviewing the whole change.

She gives two ways to set them up:

• In the prompt. Say what done looks like, ask Claude to split the work into tasks that each have their own tests, and ask it to show the actual output, since you weren’t there to see it.
• In hooks, for checks that must run. Run the linter after each file edit, the tests for what changed when a task is marked complete, and the whole suite before the session ends.

One detail matters for hooks. Most tools exit with code 1 when a test fails, and Claude Code treats that as a non-blocking error, so the task is marked complete anyway. Exit with code 2 and Claude is sent back to fix it.

CI and review

Every session ends in a pull request, and CI runs the same checks on each one however the session was set up. With auto-fix turned on, Claude watches the pull request, sees a failed check and pushes a fix, so your review time doesn’t go to things a check could have caught.

She describes her own team’s review by risk:

• Every pull request is reviewed by Claude first, in a fresh context and not by the session that wrote it, with a second group of agents double-checking each bug it finds.
• Docs and copy changes need no person once the automated checks are green.
• Ordinary product changes get one human reviewer.
• Risky changes might get two.

For some low-risk changes she says you can let GitHub merge the pull request by itself once the checks pass, but that isn’t the default.

Projects and the coordinator

Her last step is not starting every session yourself. In Claude Code projects, you talk to one main session, which Anthropic calls the coordinator. It splits the request into tasks, starts a thread for each one, tracks what comes back and sends back anything that isn’t done. Each thread is usually its own cloud session, and in her telling the coordinator doesn’t write code.

You can set the models separately. She suggests a model that’s strong at deciding and judging for the coordinator, naming Fable, and one that’s strong at doing the work for the threads, naming Opus 5.5. She also says projects manage context for you, so there’s no deciding when to compact or clear.

The docs say projects are in public beta on Pro, Max and Ultra plans and rolling out gradually, starting with accounts that have used cloud sessions.

How to try it

Her closing advice, in order:

• Pick one task much bigger than you’d normally hand to Claude.
• Make sure CI catches the things you care about.
• Spend some time on the cloud environment: its network access, its secrets and its setup script.
• Start the task in the cloud, then watch where the session gets stuck and where you’re still in the loop. That’s the next job to hand over.

A prompt to compare your setup

The talk left me wanting to hold my own setup up against hers, so here’s a prompt that does it. Paste it into Claude Code at the root of a project. It only reads.

Compare my Claude Code setup with the one Lydia Hallie
describes in her talk "Rethinking Claude Code Best Practices".
Read only. Don't change, create or delete anything, and don't
print the value of any secret or key.

Read what exists of: CLAUDE.md and any other instruction files
in this project, .claude/settings.json and
.claude/settings.local.json, my user-level ~/.claude/CLAUDE.md
and ~/.claude/settings.json, any hook scripts those settings
point to, and the CI workflow files in this repository.

Then check these eight things and answer each from what you
read:

1. Instructions. Do the instruction files hold only what you
couldn't learn from the code? List lines that shout (IMPORTANT,
NEVER, ALWAYS) or restate the stack or folder layout.
2. Permission mode. Is auto mode the default? Are trusted
repositories, buckets or domains described for it
(autoMode.environment)?
3. Deny rules. Is there a deny rule for each thing that can't
be taken back: reading secret files such as .env and keys,
force pushes, discarding uncommitted work?
4. Sandbox. Is the sandbox on for shell commands? Does it block
reads of credential folders such as ~/.ssh, and limit which
hosts commands can reach?
5. Checks while working. Are there hooks that run a linter
after edits, tests when a task is marked complete, and the full
suite before the session stops?
6. Hook exit codes. Does every hook that's meant to block exit
with code 2 on failure? Exit code 1 doesn't send you back to
fix anything.
7. CI. Does CI run the tests on every pull request, and would
it catch the failures I'd care about?
8. Cloud sessions and projects. You can't see my cloud
environments from here, so list the questions I should answer
myself: network access, secrets, setup script, and whether one
session coordinates the others.

Report one table with a row per item: what the talk recommends,
what I have (with the file and line), and a verdict of matches,
partly or missing. Mark anything you couldn't see as "can't
tell from here" instead of guessing. End with the three changes
that would take me out of the loop the most, in order, each
with the exact setting or file to change. Don't make the
changes.

What it produced. I tested it in a fresh session on a scratch repository with a deliberately dated setup. It came back with the eight-row table and found each planted fault:

• The two shouted lines and the line restating the stack, while keeping the one line the code couldn’t show.
• No deny rule for the .env file or for discarding uncommitted work.
• A lint hook that exits with code 1, so a failure never comes back to Claude.
• A CI workflow that never runs the tests.

It left the .env file unopened, listed the cloud questions for me to answer, and ended with three ordered changes.

What it doesn’t give you.

• It hasn’t watched the talk. The eight checks in the prompt carry her advice, so the “talk recommends” column restates the prompt.
• It reads your user-level settings as well as the project’s, so the report describes both.
• The setting names in its suggested fixes come from the model’s memory. In the test it said so itself. Check them against the Claude Code docs before applying one.
• It treats exit code 2 as the only way a hook blocks. The hooks docs also describe an onFailure setting for some hook events, so a hook that uses it may get the wrong verdict.
• It can’t see cloud environments or GitHub branch protection.

Last verified Nov 12, 2026.

Key terms

Harness

Claude Code itself, as opposed to the model: the permission rules, hooks and settings that are enforced whatever the model decides.

Auto mode

A permission mode where a separate classifier model reviews each action before it runs, in place of you approving it.

Deny rule

A permission rule that blocks a tool call outright. It's checked before the classifier, which never sees the call.

Sandbox

Operating-system limits on which files and hosts a shell command, and anything it starts, can reach.

Cloud session

A Claude Code session on its own virtual machine with a fresh copy of the repository. It keeps running with your laptop closed.

Hook

A script Claude Code runs at a set point, such as after a file edit or when a task is marked complete.

Coordinator

Anthropic's name for the main session in a Claude Code project. It splits the work, starts a thread for each task and judges what comes back. Hallie calls it the orchestrator.

Quotes from the talk