cd /news/ai-tools/lid-closed-claude-code-still-running… · home › topics › ai-tools › article
[ARTICLE · art-156507] src=dev.to ↗ pub= topic=ai-tools verified=true sentiment=↓ negative

Lid closed, Claude Code still running: how macOS DarkWakes burn your weekly limit overnight

A developer documented how macOS DarkWakes cause Claude Code sessions to fail and burn weekly usage limits when a MacBook lid is closed mid-task. Across four GitHub issues filed October 15-18, one reporter saw 81 requests sent but only 29 completed over 6.5 hours, with the weekly limit jumping from 20% to 56%, while a second saw usage rise from about 9% to 19% in 2.2 hours. The writeup recommends either running `sudo pmset -a disablesleep 1` to keep the machine awake until the task finishes or interrupting the turn before closing the lid, and notes that disabling Power Nap only reduces retries.

by read4 min views2 publishedOct 24, 2026

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.

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:

StreamSuspended) and reports Connection lost while your computer was asleep. 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.

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.

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.

── more in #ai-tools 4 stories · sorted by recency
── more on @anthropic 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
→ Live at https://your-agent.zahid.host ✓
Get free account → Pricing
from €0/mo · no card required
LIVE [news/lid-closed-claude-co…] indexed:0 read:4min 2026-10-24 · —