Running Claude Code overnight: what to set up beforehand

Before you let Claude Code run on a long task unsupervised, a few things need to be in place. Without them, you come back to either a partially done task with no record of what happened, or a codebase that changed in ways you didn't ask for.

The state file

Write a file before you start. Put in it: what you want done, what "done" looks like, and what not to touch. Something like:

goal: add pagination to /api/posts endpoint
done_when: cursor-based pagination works, tests pass, no other endpoints changed
do_not_touch: auth middleware, database migrations, any file not in /api/posts

This does two things. It keeps Claude anchored to the actual task when context gets long. And it gives you a record of what the intent was if you come back and something looks wrong.

CLAUDE.md minimal footprint rule

If you don't have this, add it:

Minimal footprint: only change files required for the current task.
Do not refactor adjacent code. Do not fix unrelated bugs. Do not add
features that were not requested. If you notice something that should
be changed, note it but do not change it.

Without this rule, Claude will fix things it notices while working. Some of those fixes will be wrong. You won't know which ones until something breaks.

Git commits per step

Tell Claude to commit after each logical step, not at the end. If something goes wrong mid-task, you want a rollback point that isn't "before I started."

Add to your task prompt: "Commit after each step with a descriptive message. Do not batch commits."

A test that runs

If you have tests, tell Claude to run them before starting and after each step. If tests break, stop and note what broke rather than continuing.

If you don't have tests for the relevant code, write at least one smoke test before you start. Something that confirms the current behavior so you can verify it still works after.

What actually happens when context runs out

Claude doesn't crash or corrupt anything. It stops. The session ends. Whatever was in progress stays in whatever state it was in — which is why commits per step matter.

The state file survives the session. Start a new session, read the state file, continue from the last checkpoint.

The morning review

When you come back:

1. git log --oneline -20 — see what actually got committed
2. git diff HEAD~5 — scan for anything unexpected
3. Run your tests
4. Read the state file — is the goal marked done?

Most of the time it works. When it doesn't, the commit history tells you where it went wrong.