Claude Code Best Practices From 4 Months of Unattended Runs (Not From One Weekend Project)

Most Claude Code best practices lists were written by someone sitting in front of the terminal. Plan first. Keep CLAUDE.md tight. Use plan mode. Write tests. Clear your context. All good advice, and all of it assumes a human is watching the session, ready to hit Escape when things go sideways.

Mine mostly run while I’m asleep. The container writing this post has been running scheduled Claude Code jobs since June 12, 2026: 1,740 run logs through yesterday, 39 skill files, one cron slot after another, from blog posts to inbox triage to backlink outreach. Nobody approves the plan. Nobody reads the diff before it ships. If something breaks at 00:07, I find out at breakfast, if I find out at all.

That changes which best practices matter. So this isn’t a list of tips I read. It’s nine rules, each with the dated incident that taught it, plus the popular ones I dropped because they didn’t survive unattended use. If you’re about to put Claude Code on a schedule, this is the list I wish I’d had in June.

Why Most Claude Code Best Practices Assume You’re Watching

I read the pages that rank for this term before writing this. They split into three shapes:

• Curated link hubs. The top GitHub result is a big index of concepts, workflows and 83 tips. Useful as a map, but it’s a map.
• Personal project write-ups. Rebuilding a blog, trying BMAD before writing code, finding where plan mode runs out. Honest, hands-on, and always one developer in one interactive session.
• Tutorials and official tips. DataCamp’s guide is the most complete: planning cycles, layered CLAUDE.md, the Document & Clear pattern, hooks as guardrails, TDD, model cost. Anthropic’s own Claude Code power user tips cover parallel sessions, worktrees, skills, hooks, permissions, /loop and /schedule.

Anthropic’s page says the number one tip is verification: give Claude a way to check its own work and it iterates until the output is right. I agree completely. Most of this post is what that tip turns into once there’s no human in the loop to notice when the check itself is wrong.

Here’s the gap. Every one of those guides is about getting a good result this session. When Claude Code runs on cron, the problems are different:

• A run can fail and still look like success.
• A run can succeed and nobody can tell, because it never said so.
• A fix can ship and not run in production for days.
• The agent can edit the files that tell it how to behave.

You don’t learn those by watching. You learn them from the logs the next morning. For the architecture itself (cron fires, a skill file loads, Claude does the job, the container sleeps), I wrote that up in Claude Code agents in production. This post is about the rules on top of it.

Practices 1–3: Scope the Run and Give It a Result Contract

1. One run, one job, one skill file

Every slot in my schedule maps to exactly one skill: blog-writer at 00:07, daily-contribution at 07:07, email-checker at 11:07, and so on. The dispatcher runs claude --print with a single instruction: read this skill file and execute it. No “and while you’re there, also…”.

The reason is debuggability, not elegance. When a run goes wrong, I want one log, one skill, one owner. Multi-purpose sessions turn every failure into an argument about which half caused it. If you do something more than once, Anthropic’s advice is to turn it into a skill. For scheduled work, I’d go further: if it isn’t a skill, it doesn’t get a slot.

2. Give every run a timeout, and make the timeout loud

My scheduler gives each job a hard ceiling: 30 minutes by default, 90 for the blog writer. Good. What I got wrong was the silence. 16 runs were killed by the timeout between June and October, and every one of those logs is a 7-line header and nothing else. No alert, no footer, no clue. I covered that census in give every AI agent a timeout, then make it loud. The rule: a killed run should be the loudest event of the day, not the quietest.

3. End every run with one machine-readable result line

This is the practice I’d put first if I could only keep one. Every skill must finish with:

SKILL_RESULT: success | what happened | url
SKILL_RESULT: skip | why nothing was done
SKILL_RESULT: fail | what broke

That line is a contract. A watchdog can grep it, a dashboard can count it, and I can read 20 of them over coffee. Here’s the scoreboard across 1,740 runs:

Outcome	Runs
success	1,370
skip (empty queue, nothing to do)	210
fail	42
other (degraded, malformed)	5
no result line at all	113

Those 113 are the problem. 47 of them exited with code 0: the process said “fine” and the agent said nothing. A watchdog that trusts exit codes passes them. A watchdog that greps for the result line flags them as failures, including some that actually published. Either way you’re guessing. I wrote up the quietest of these in your quietest AI agent is the one to check first.

The fix isn’t a firmer instruction. It’s a check that runs after the agent finishes: no result line, no green light. Which brings us to the file everyone over-trusts.

CLAUDE.md Is One File, Not the Whole System

Every Claude Code best practice list spends a section on CLAUDE.md. I wrote a whole post on it, CLAUDE.md best practices from a file that runs 10 unattended businesses, so I won’t repeat it here. One finding from that audit matters for everything else in this post.

My CLAUDE.md has a “Non-Negotiable” rules block. Same heading, same emphasis. When I measured compliance across the logs, the two rules that live inside the API call that creates a post (publish status, featured image) scored 100%. The “end with a SKILL_RESULT line” rule scored about 92%. And “always read MEMORY.md at the start of every session” scored 0%, because that file is now 2.1 MB. No context window holds it.

Compliance followed the critical path, not the bold text. If a rule sits inside a step the agent can’t skip, it happens. If it’s a closing ritual nothing checks, it sometimes doesn’t. If it’s impossible, it never does.

So here’s the division of labour I use now:

• CLAUDE.md: identity, voice, IDs, and pointers. What the agent needs to know, not everything it must do.
• Skill files: the procedure for one job, step by step, with the exact API shapes.
• Hooks and wrapper scripts: anything that must happen every single time. Anthropic describes hooks as deterministic logic at points in the agent lifecycle. That’s the point: a Stop hook that checks for a result line doesn’t depend on the model remembering.
• Subagents: isolated side quests that would otherwise flood the main context. More on that in Claude Code subagents in production.

Practices 4–6: Trust Nothing That Looks Like Success

This is where the unattended Claude Code best practices really part ways with the interactive ones. When you’re watching, a weird response looks weird. At 3 a.m., a weird response that’s shaped like success gets logged as success and the agent moves on. These three rules all came from that.

4. Check the payload, not the status code

My SEO data provider once ran out of credit. Every call still came back HTTP 200 with a top-level status of 20000 Ok.. The actual error, 40200 Payment Required, sat one level down inside the task object. An agent that checks the HTTP status sees a clean run with no data in it. Full story in the SEO API that says “Ok.” when it means “pay me”.

The rule: for every external API, write down where the real status lives, and have the skill check that field, not the envelope.

5. Treat “zero results” as a question, not an answer

This one cost me months. My blog agent picks its next keyword from an Airtable table. Airtable formula field names are case-insensitive, but field names in a write are case-sensitive. My table used lowercase status; the skill wrote Status. Every update came back 422 UNKNOWN_FIELD_NAME.

The read side had its own version: the query sorted by Search Volume when the field is search_volume. That call failed with a 422 too, and the skill saw zero records. Zero records is byte-for-byte what an empty queue looks like, and the skill had a polite “queue empty, skip” branch. So the failure got reported as a clean skip. The first keyword that agent ever successfully marked as published was on October 8. It had been “working” since June.

Same family, still open today: my image script logs every generated image to Airtable using a field called Name that doesn’t exist on that table. Airtable rejects the whole row, and the script exits 0. Unless a run backfills the row by hand, the image simply goes unlogged. Error handling that turns a 422 into an empty list is the most dangerous code in an unattended system, because it’s designed to stay quiet.

6. Verify on the artifact the user sees

My SEO plugin’s API answers {"slug":true} whether or not the meta title actually changed. For a week I thought I had to send every update twice. I didn’t. The page cache was serving the old head. The real fix was to verify the live page with a cache-busting query string, then trust what’s on the page and not the acknowledgement.

Another one, from October 7: a compliance scan read a JSON key called narration when the script text lived under text. It graded 50 of 531 characters and reported all clear. Nothing errored. It just checked the wrong thing, confidently.

So my blog skill now re-fetches every post after publishing and checks the live HTML for the title, the meta description and the featured image. Anthropic calls verification the #1 tip. For unattended work, I’d sharpen it: verify the thing a customer would see, through the same door they’d use.

Practices 7–9: Backups Before Self-Edits, Budget Caps, and a Nightly Watchdog

7. Back up any file before the agent edits it

My agents update their own memory files after every run. That’s how they learn the things in this post. It’s also how a bad run could wipe four months of notes. So every skill copies the file before touching it. Current count in the project folder: 264 backups of MEMORY.md, 231 of the observations log, and 31 of skill files.

That looks like clutter. It’s actually the undo button I’ve needed more than once, including the morning a reused helper script was cut off mid-function, looked like it had done nothing, got run again, and created two duplicate Asana tasks. Cheap insurance: a timestamped cp before any write to a file the agent reads its instructions from.

The flip side is worth saying out loud. In a container with --dangerously-skip-permissions, the agent can edit its own .claude settings. I documented that open gap in my Claude Code sandbox audit. Backups make self-edits reversible. They don’t make them safe.

8. Cap the budget per run, not per month

Monthly caps tell you about a disaster after it’s finished. Per-run caps stop it while it’s happening. Mine are mostly structural:

• Time: the per-job timeout from practice 2.
• Volume: the skill says how many. One blog post. Three to five Reddit discoveries. Five outreach leads. Never “as many as you can.”
• Parallelism: image generation fired 8 calls at once and got 3 rate-limit rejections. Batches of 3 with a short stagger went 12 for 12. Details in AI agent rate limits.
• Spend: image models are priced per image, so the skill fixes the count. Seven images for a long post, one for a short one.

The model itself sits on a flat plan, which is the other half of cost control: the variable spend is in the tools the agent calls, so that’s where the caps go.

9. Run a nightly watchdog, and keep it out of the way

At 23:35 every night a watchdog skill reads the day’s logs, checks every scheduled slot fired, and grades each result. It’s caught things nothing else would: disconnected social accounts, a skipped slot, runs with no result line.

It also taught me the strangest lesson in this list. When I looked for runs that overlapped in time, I found 22 overlapping pairs, and all 22 started in the 23:28–23:40 window. The schedule itself never collided. The watchdog did, by re-running failed jobs inline while it was still running. On October 7 a 25-minute retry pushed past midnight, and that night’s blog post never fired.

So the rule is two rules. Have a watchdog. And never let a recovery action run longer than the gap before the next slot, or the fix reproduces the failure it’s fixing. Report and queue; don’t retry heroically.

If you’d rather not learn these one incident at a time, this is the kind of system I build for clients. A short strategy call is the fastest way to find out whether your workflow is ready to run unattended.

The Claude Code Best Practices I Dropped

Some popular advice is right for a developer at the keyboard and wrong for an agent on cron. Here’s what I stopped doing.

“Always read the memory file first”

Fine at 5 KB. Impossible at 2.1 MB. I still keep the rule in CLAUDE.md as a reminder of how instructions rot. What works now: each skill searches memory for its own name and reads the most recent entries. Targeted recall beats total recall.

“Approve the plan before Claude writes code”

Plan mode is great when someone reads the plan. At 00:07 nobody does. I replaced it with a split: an upstream research agent writes a brief into the content calendar (keyword data, the live search results, an outline, a scope fence saying what not to cover), and the writing agent executes against it. The plan still exists. It’s just written a day early and checked by the next agent, not by me.

“Run everything in parallel”

Parallel sessions and worktrees are fantastic for a developer juggling tasks. On a single container with shared API quotas, more parallelism mostly bought me rate limits (practice 8). Sequential slots with clear gaps have been more reliable than any clever concurrency.

“Use /loop for recurring work”

/loop is handy, but by Anthropic’s own docs it schedules locally for up to 3 days at a time. That’s a session feature. A business needs a scheduler that survives reboots and logs every dispatch. Mine is plain cron-style scheduling inside the container, calling claude --print per slot. Boring, and 1,740 runs and counting.

“Test-driven development”

TDD is the right call for code. Most of my agents don’t write code. They write posts, triage email and update tables. The equivalent for them is practice 6: verify the published artifact. The principle survives; the tool changes.

“A smarter model will fix it”

Of the 40 failed runs I classified in October, 38 were an expired social media API token, one was an image compression quota and one was an empty SEO data balance. Zero were the model getting something wrong. The full breakdown is in “a smarter AI model will fix your agent”. Plumbing fails. Upgrade the plumbing.

Claude Code Best Practices FAQ

What is the single most important Claude Code best practice?

Verification. Anthropic says so, and four months of unattended runs agree. Just make sure you verify the real outcome (the live page, the record in the table, the email in the outbox) and not the API’s description of it.

Can Claude Code run unattended on a schedule?

Yes. claude --print runs a single prompt non-interactively, so any scheduler can call it. I run it from a scheduler inside a Docker container, one skill per slot. Anthropic also offers /schedule for cloud jobs and /loop for short local loops. My operator setup is in the Claude Code CLI guide.

Is –dangerously-skip-permissions safe?

Only inside a box you’ve audited. Anthropic recommends a /permissions allowlist over skipping permissions, and lists skipping as an option for sandboxed environments. My containers run non-root with no added capabilities, but they still hold real API keys. Read the sandbox audit and the Claude Code security guide before you copy that flag.

How do I keep Claude Code from breaking when it updates?

Update one container first, let a scheduled run pass, then roll it out to the rest. Otherwise an update can land in the middle of a job. I covered the routine in how to update Claude Code without breaking a running fleet.

Should Claude review its own work?

It helps, but don’t make it the only check. A model grading its own output shares its own blind spots. Use a deterministic check where you can and a separate review pass where you can’t. More in Claude Code review.

How much does it cost to run Claude Code like this?

The model runs on a flat Max plan. The variable cost is the tools: roughly $0.08 per generated image and about $0.33 per short video in my pipeline. Per-run caps (practice 8) are what keep those predictable.

Final Thoughts: Claude Code Best Practices for When You’re Asleep

The interactive Claude Code best practices are about getting a great result while you watch. The unattended ones are about knowing what happened when you didn’t. Here’s the short version:

1. One run, one job, one skill file.
2. Every job gets a timeout, and a killed run is loud.
3. Every run ends with one result line, and a check enforces it.
4. Read the real status field, not the envelope.
5. Treat zero results as a question.
6. Verify the artifact the customer sees.
7. Back up any file before the agent edits it.
8. Cap time, volume, parallelism and spend per run.
9. Run a watchdog that reports, and never let a retry overrun the next slot.

None of these came from a tutorial. Each one came from a log I read the next morning. That’s the real best practice: read your logs like they’re the product, because when nobody’s watching, they’re the only witness you’ve got.

Start with practice 3. Add the result line to one scheduled job this week and count how many runs can’t tell you what they did. That number will tell you what to fix next.