The Mac that doesn't sleep

What it is and why it matters

Claude Code can work for hours even when you're not there. One evening I really wrote it: “I'm going to sleep, you have full authority.” The next morning the build was live.

But it only works if you leave it three things: a clear goal, a way to check its own work, and a limit on what it can touch.

Without a goal it spins its wheels. Without a way to check, it tells you everything is fine. Without limits it can do damage. With all three, in the morning you find the work and a list of decisions to approve, not surprises.

1. The evening message

I write it in the Claude Code session open on the project, as the last message before going to bed. Copy it and fill in the parts between [ ].

I'm going to sleep. You have full authority over this job until tomorrow morning.

GOAL
[One sentence, concrete. E.g. "The new pricing page, live on the test site".]
You're done when: [e.g. "the page opens on a phone and the buttons lead to the test checkout"].

HOW YOU CHECK YOUR OWN WORK
- Run the tests after every change and don't move on if one fails.
- Open the page in the browser and take a screenshot of every finished screen.
- Don't tell me "done" without proof: the command you used and the result.

LIMITS (what you may NOT touch)
- The real database, user data, real payments.
- Don't delete files, don't publish to the App Store, don't change the keys.
- If you need to do one of these things to move forward: stop and write to me.

IF YOU GET STUCK
Try two different approaches. If neither works, write down where you stopped and move on to the next part.

IN THE MORNING
Leave me a summary: what you did, what you decided on your own and why, what you need from me.

How to fill in the parts between [ ]

• Goal: just one thing. “Fix the site” isn't a goal. “The new pricing page, live on the test site” is.
• “You're done when”: write what you would see, with your own eyes, if the work were done. It's the line that tells it when to stop.
• The tests must already exist and pass before you go to sleep. If you don't have any, tonight's job can be writing them.
• Claude can only take the screenshots if it has a way to open the browser, for example connected to Chrome. If it doesn't, remove that line or put in a check it can do from the terminal.

2. Before you turn off the light

If the Mac goes to sleep, Claude stops too. Before pasting the message I do four things:

1. I save everything with a commit. That way, in the morning, the changes show only the night's work.
2. I plug in the charger.
3. I leave the laptop open. Closing the lid puts it to sleep, even with the settings that keep it awake.
4. I stop it from sleeping. In the Claude desktop app there's the Keep computer awake option, under Settings > This computer > System. From the terminal I use a command the Mac already has: caffeinate.

From the terminal I start Claude Code like this:

caffeinate -i claude

caffeinate -i keeps the Mac awake as long as Claude Code stays open. When you close it, the Mac goes back to behaving as usual. The screen can still turn off, that doesn't change anything.

3. Don't leave it stuck waiting for a yes

In Manual mode, Claude Code asks your permission before most edits and commands. At night that means that at the first question it sits there until you wake up.

That's why, before going to sleep, I check which mode I'm in. In the terminal you change it with Shift+Tab and you see it written under the prompt. At night I use one of these two:

• auto: Claude works without asking you anything, and a second model checks actions before they run, blocking the risky ones (production deploys, mass deletions, force push). It also takes into account the limits written in the message. If you don't find it with Shift+Tab, your account or model doesn't have it: use the other one.
• acceptEdits: it accepts file edits on its own, plus a few basic commands, like creating or moving folders. For other commands it would ask, so it goes together with the allow rules you see below, to let it run at least the tests.

One thing to know about auto mode: if it blocks an action 3 times in a row, or 20 in total, it pauses and Claude goes back to asking your permission. If in the morning you find it stopped on a question, look at what it wanted to do: that's exactly one of the decisions that are yours to make.

The one that skips all permissions (bypassPermissions), on the other hand, I don't use: the documentation says to use it only in isolated containers or virtual machines, not on your Mac.

4. Real limits: rules and hooks

A rule written in the message is a request; a hook is a wall. The documentation says it too, in other words: permissions are enforced by Claude Code, not by the model. What you write in the message shapes what Claude tries to do, but it doesn't change what it's allowed to do.

The allow and deny rules

They're lines in the project's .claude/settings.json file. Allow: what Claude can do without asking. Deny: what it can never do, in any mode. If something is in both allow and deny, deny wins. You can also see and edit them by typing /permissions inside Claude Code.

During the day I ask Claude to set them up:

Add to this project's .claude/settings.json file an allow rule to run the tests without asking me, and deny rules for: git push, rm commands, edits to the .env file. Show me the file before you save it.

It should come out more or less like this (instead of npm test, put your project's test command):

{
  "permissions": {
    "allow": ["Bash(npm test *)"],
    "deny": [
      "Bash(git push *)",
      "Bash(rm *)",
      "Edit(./.env)"
    ]
  }
}

Careful: a rule blocks the command written that way, not the same program run in another form. That's why the limits stay in the message too, and it's better if the real keys aren't in the project at all.

The hook on dangerous commands

A hook is a command that Claude Code runs on its own at a precise moment. The one you need here is called PreToolUse: it fires before Claude uses a tool, for example before every terminal command. The script looks at the command and, if it exits with code 2, Claude Code blocks it and passes the reason to Claude, so it takes another route. It also blocks commands that an allow rule would let through.

You don't have to write it yourself. I ask Claude, again during the day:

Create a PreToolUse hook for this project, in .claude/settings.json, that blocks Bash commands containing: rm -rf, git push --force, [the command you use to publish your app]. The script must exit with code 2 and write the reason for the block. Then test it: show me that a forbidden command really gets stopped and that a normal command goes through.

Then I type /hooks in Claude Code and check that it shows up in the list, under PreToolUse.

5. The next morning

The first thing I read is the summary, especially the “what you decided on your own” part. That's where the things to approve are. Then I rerun one of the commands it used as proof myself: if I get a different result, that proof doesn't count.

And in the same session I ask:

Show me the list of files you changed last night. For each decision you made on your own, tell me what happens if I undo it.

Common mistakes

• Leaving it in Manual mode: at the first permission request it stops until morning. Before you leave, pick the mode and set up the allow rules.
• A vague goal, like “improve the app”: it works all night and you don't know on what. Write a single thing, with the “you're done when” line.
• Closing the lid or leaving it on battery: the Mac goes to sleep or runs flat in the middle of the night. Leave it open, plugged into the charger, with caffeinate or the option that keeps it awake.
• Trusting only the limits written in the message: they're a request, and in a long conversation they can get lost. For things that must never happen, add a deny rule or a hook.

Checklist

• One goal in one sentence and the “you're done when” line
• The tests exist and pass before the night starts
• Everything saved with a commit before the night
• Mode chosen: auto, or acceptEdits with the allow rules
• Deny rules and hook tested during the day
• Charger plugged in, lid open, Mac that won't go to sleep
• The evening message pasted, with your limits

Frequently asked questions