MacBook 合上螢幕後，Claude Code 如何因 macOS DarkWakes 消耗每週用量

You start a long Claude Code task, close the MacBook lid, and go to bed. In the morning the task isn't done, the log is full of Connection lost while your computer was asleep, and your weekly limit is 20 or 30 points lower than when you left. Nothing useful was produced.

Four reports of this landed on the Claude Code tracker between October 15 and 18 (#102597, #102269, #103064, #103233). The logs in two of them are detailed enough to see exactly what happens, so here is the mechanism and what you can do about it today.

A sleeping Mac isn't asleep

Closing the lid puts the Mac into Clamshell Sleep. But macOS keeps waking it for a few seconds at a time, screen off, to run maintenance, Power Nap, network and "Sleep Service" chores. These are DarkWakes, and pmset -g log shows them:

pmset -g log | grep -E "DarkWake|Clamshell"

In the #103064 log they came every 15 to 20 minutes and lasted 2 to 7 seconds, plus one 27-minute maintenance wake once the Mac was on AC power. In #102597 there were 26 wake cycles in 6.5 hours, about one every 15 minutes.

Programs run during those seconds. A Claude Code session that was mid-stream when the lid closed does this on every wake:

Its watchdog sees the clock jump, aborts the frozen stream (StreamSuspended) and reports Connection lost while your computer was asleep.
It re-sends the request, which means the whole conversation context again.
The Mac goes back to sleep 2 to 7 seconds later, mid-stream. Back to step 1.

What that costs

The numbers from the two detailed reports, as the reporters measured them from their own transcripts and debug logs:

	#102597 (2 background subagents, battery)	#103064 (1 foreground session, desktop app)
Lid closed for	6.5 h	2.2 h
Requests sent	81	29
Completed	29	25
Context per request	400K to 580K tokens	648K to 728K tokens
Prompt cache	cold on 15 of the completed calls (about 7.1M tokens of `cache_creation`)	warm throughout
Output produced	about 7K tokens	task finished during the 27-minute wake
Weekly usage	20% → 56%	about 9% → 19%

Two things stand out. First, a foreground session does this too, not just background agents, and the desktop app's Code tab is no different from the CLI. Second, in the background-agent case the prompt cache was cold on half the completed calls, so each of those re-sent 400K+ tokens as a fresh cache write. The log shows 404 No thread state was found followed by forcing create for retry: replay_not_found eleven times, which looks like the reason, but I can only guess from outside. Neither reporter can see what the aborted requests were charged; that part only Anthropic can answer, and both issues ask for it.

Fixing it yourself

The expensive state is the one in between: a Mac that is neither awake nor fully stopped. Before you close the lid, pick one.

Keep it awake to the end. The only thing that stops lid-close sleep on a MacBook is:

sudo pmset -a disablesleep 1

The stream never gets cut, so nothing is re-sent. It survives restarts, so set it back with sudo pmset -a disablesleep 0 when the task is done, or the Mac stays awake in your bag. Keep it on a hard surface; it will run warm.

Or really stop it. Press Esc to interrupt the turn, and make sure no background agents are still running, before the lid goes down. With nothing in flight, the DarkWakes cost nothing.

Fewer wakes helps a little. sudo pmset -a powernap 0 removes the longer Power Nap wakes. The short maintenance and Sleep Service wakes remain, so this reduces the retries rather than ending them.

If it already happened to you, your transcript (~/.claude/projects/...jsonl) and pmset -g log have the same data the reporters used. Adding your numbers to those issues is the most useful thing you can do; the open question is how aborted requests count against the limit, and more cases make it easier to answer.

Doing it only while work runs

I build Lidnight, a menu bar app for exactly this gap. It uses Claude Code's and Codex's hooks to know when a turn is running and keeps the Mac fully awake only then, lid closed and on battery too, background sessions included. Once every session has been quiet for ten minutes it restores disablesleep and lets the Mac sleep, and it undoes a leftover disablesleep at boot so a crash can't leave the Mac stuck awake. Working means no DarkWake gaps to re-send across; sleeping means nothing left in flight. Staying awake with the lid closed is a Pro feature and is included in the 7-day trial.

The hooks themselves are plain shell. If you'd rather wire this up yourself, the caffeinate recipe in claude-code-hooks-recipes keeps the Mac awake per session (it can't block lid-close sleep, so pair it with disablesleep for that), and the longer write-up with the Korean and Japanese versions is on lidnight.app.