DEV Community: Dawon Lee

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

Dawon Lee — Sat, 24 Oct 2026 01:36:08 +0000

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.

Claude Code Remote Control stops when you close the lid. Here's why, and the fix

Dawon Lee — Thu, 22 Oct 2026 22:52:59 +0000

Claude Code's Remote Control is great: run claude remote-control (or /remote-control in a session), scan the QR code with the Claude app, and you can keep steering the session from your phone on the couch. Turn on Push when actions required in /config and permission prompts and questions arrive as pushes.

Then you close the MacBook lid, and the session goes quiet.

Why

The session runs on your Mac. Remote Control is a window into it, not a copy of it. When the Mac sleeps, Claude stops. The docs say exactly this:

if your laptop sleeps or your network drops, Claude Code reconnects automatically when your machine comes back online.

So it reconnects afterwards. Nothing runs while the Mac is asleep, and the message you sent from your phone waits until the lid opens again.

Closing the lid without an external display puts a MacBook to sleep regardless of caffeinate. Claude Code already runs caffeinate -i while it works, which only blocks idle sleep.

Fixing it yourself

Lid open, on power. Nothing to do. caffeinate -i keeps the Mac awake while a turn runs. If the light bothers you, pmset displaysleepnow turns the screen off without sleeping.

Lid closed (bag, bedside). The only thing that stops lid-close sleep is:

sudo pmset -a disablesleep 1

Two things to know before you do that:

It survives restarts, and if you forget to run sudo pmset -a disablesleep 0 afterwards, the Mac stays awake in your bag, draining and heating. Keep it on a hard, ventilated surface.
On battery you get a few hours at most, and a Mac that's awake but idle will keep polling. If a turn is mid-stream when the Mac finally sleeps, you get the "went to sleep mid-response" retries.

Knowing when it's done. Besides Remote Control's own pushes, a Stop hook can ping you. I keep copy-paste versions of that (and of answering AskUserQuestion from a hook) in claude-code-hooks-recipes.

Doing it only while work runs

I build Lidnight, a menu bar app that takes just the part Remote Control leaves out: it uses Claude Code's and Codex's hooks to keep the Mac awake only while a turn is running (lid closed, on battery too), and once every session has been quiet for ten minutes it restores disablesleep and lets the Mac sleep. It also undoes a leftover disablesleep at boot, so a crash can't leave your Mac stuck awake.

Remote Control stays exactly as it is. Continue from your phone, leave the lid closed, and the Mac sleeps on its own when the work is done.

You can answer Claude Code's AskUserQuestion from a hook (and from your phone)

Dawon Lee — Wed, 21 Oct 2026 11:26:55 +0000

Claude Code sometimes stops and asks you a multiple-choice question with the AskUserQuestion tool ("Which framework?", "Keep the old API or replace it?"). If you're away from the terminal, the run just sits there.

The hooks docs describe answering it in -p mode: a PreToolUse hook returns allow plus an updatedInput that carries the answers. I wanted to know if the same works in a normal interactive session through a PermissionRequest hook, so I tested it on Claude Code 2.1.283. It does.

What the hook receives

When Claude calls AskUserQuestion in an interactive session, a PermissionRequest hook gets this on stdin (trimmed):

{
  "hook_event_name": "PermissionRequest",
  "tool_name": "AskUserQuestion",
  "tool_input": {
    "questions": [
      {
        "question": "Which color do you want?",
        "header": "Color",
        "options": [
          { "label": "Red", "description": "red" },
          { "label": "Blue", "description": "blue" }
        ],
        "multiSelect": false
      }
    ]
  }
}

What the hook returns

Copy tool_input, add an answers object that maps each question's text to the chosen label (comma-separated for multi-select), and return it as updatedInput with behavior: "allow":

{
  "hookSpecificOutput": {
    "hookEventName": "PermissionRequest",
    "decision": {
      "behavior": "allow",
      "updatedInput": {
        "questions": [ ...same as input... ],
        "answers": { "Which color do you want?": "Blue" }
      }
    }
  }
}

Claude Code then shows:

⏺ User answered Claude's questions:
  ⎿  · Which color do you want? → Blue
  ⎿  Allowed by PermissionRequest hook

and Claude continues with "Blue". No terminal prompt appears.

A minimal test hook

#!/bin/sh
# Answers every AskUserQuestion with the last option. For testing only.
python3 -c '
import json, sys
d = json.load(sys.stdin)
if d.get("tool_name") != "AskUserQuestion":
    sys.exit(0)  # no decision: the normal permission prompt shows
ti = d["tool_input"]
ti["answers"] = {q["question"]: q["options"][-1]["label"] for q in ti.get("questions", [])}
print(json.dumps({"hookSpecificOutput": {"hookEventName": "PermissionRequest",
      "decision": {"behavior": "allow", "updatedInput": ti}}}))
'

Two things to watch

allow alone doesn't answer the question. If your approval hook (or an approval app) just returns allow for AskUserQuestion, the question stays open and the session still waits. I hit exactly this: my phone approval said "allowed", but Claude was still waiting.
The hook blocks until it returns. To answer from somewhere else, the hook has to wait for that answer (and give up before the hook timeout so the terminal prompt still works).

Using it from a phone

I build Lidnight, a menu bar app that keeps a Mac awake while Claude Code and Codex work. Version 1.7.79 uses this: when Claude asks a question, the options show up on the phone status page (end-to-end encrypted) and in the Mac menu bar, and the one you tap goes back to Claude through the hook. You can still answer in the terminal; whichever comes first wins.

Update: the hook above plus four more (Stop notification, ntfy phone push, caffeinate for the session, leftover processes) are collected as copy-paste scripts here: https://github.com/whereisdw/claude-code-hooks-recipes

Codex will answer its own question if you're not looking. Here's how to catch it

Dawon Lee — Sun, 18 Oct 2026 10:07:17 +0000

If you use Codex, you've probably seen this: it stops to ask you something ("Which folder should I refactor?"), and if you don't answer quickly it goes ahead with its own recommended option. People have asked for a way to turn that off, and the issue has 200+ 👍. Since 0.147, Plan mode waits for you, but per the thread, questions in default mode (the desktop app's "ask while working" questions) can still resolve themselves.

Until there's a setting, the practical fix is to find out the moment Codex asks, even when the terminal is behind three other windows or you're on the couch.

There's no hook for it

Codex hooks cover SessionStart, UserPromptSubmit, PreToolUse, PermissionRequest, PostToolUse, Stop and a few others (docs). PermissionRequest fires for approvals (shell escalation, network), not for questions. So a notify/hook setup that pings you on approvals stays silent when Codex asks a question.

But the session log has it

Every Codex session writes a JSONL rollout under ~/.codex/sessions/YYYY/MM/DD/. A question is a tool call named request_user_input:

{"type":"response_item","payload":{"type":"function_call","name":"request_user_input",
 "arguments":"{\"questions\":[{\"header\":\"Scope\",\"question\":\"Which folder should I refactor?\"}],\"isBlocking\":true}",
 "call_id":"call_…"}}

When you answer, a function_call_output with the same call_id follows. So a request_user_input call with no output yet = Codex is waiting on you.

Two caveats from checking my own logs:

The desktop app's default-mode questions show up as request_user_input_async. Those get {"accepted":true} back within a fraction of a second while Codex keeps working, so "no output yet" doesn't work for them. The script below treats any async question from the last 3 minutes as new instead. These are the ones that can still resolve without you.
The field layout above is from Codex's source (protocol/src/request_user_input.rs) and matches the envelope in my logs, but log formats aren't a stable API, so expect to adjust it someday.

A small watcher

#!/usr/bin/env python3
"""Notify (macOS) when Codex is blocked on a question you haven't answered yet."""
import json, os, subprocess, time, glob

ROOT = os.path.expanduser("~/.codex/sessions")
seen = set()

def pending(path):
    calls, done = {}, set()
    with open(path, errors="ignore") as f:
        f.seek(max(0, os.path.getsize(path) - 256_000))   # the tail is enough
        for line in f:
            if '"response_item"' not in line:
                continue
            try:
                p = json.loads(line)["payload"]
            except (ValueError, KeyError):
                continue
            if p.get("type") == "function_call_output":
                done.add(p.get("call_id"))
            elif p.get("type") == "function_call" and p.get("name") in ("request_user_input", "request_user_input_async"):
                if p["name"].endswith("_async") and time.time() - os.path.getmtime(path) > 180:
                    continue   # async: only fresh ones (they're 'accepted' instantly)
                try:
                    q = json.loads(p.get("arguments") or "{}")["questions"][0]
                    text = q.get("question") or q.get("title") or q.get("header") or ""
                except (ValueError, KeyError, IndexError):
                    text = ""
                calls[p.get("call_id")] = (text, p["name"].endswith("_async"))
    return {c: t for c, (t, is_async) in calls.items() if is_async or c not in done}

def notify(text):
    msg = (text or "Codex is waiting for your answer")[:180].replace('"', "'")
    subprocess.run(["osascript", "-e",
        f'display notification "{msg}" with title "Codex has a question" sound name "Glass"'])

while True:
    for path in glob.glob(f"{ROOT}/*/*/*/*.jsonl"):
        if time.time() - os.path.getmtime(path) > 1800:   # only live sessions
            continue
        for cid, text in pending(path).items():
            if cid not in seen:
                seen.add(cid)
                notify(text)
    time.sleep(3)

Run it in a spare terminal (python3 codex-question-alert.py). It only reads files that changed in the last 30 minutes and only the last 256 KB of each, so it's cheap. I tested it against a synthetic log (one unanswered question, one answered, one fresh async) and against a week of my real logs (no false alarms).

To get it on your phone, swap notify() for a curl to an ntfy topic.

What I did in Lidnight

I build Lidnight, a menu bar app that keeps a MacBook awake (lid closed, even on battery) while Claude Code and Codex work and lets it sleep when they're done. Version 1.7.69 does the check above on its own: when Codex asks you a question (blocking or the desktop app's async kind), you get a Mac notification and a phone push (if you've linked one) right away, with the question text. It can't answer for you. It just makes sure you see the question in time.

Lidnight is free with the lid open (AI Auto mode); a one-time Pro keeps it going with the lid closed, even on battery. Launch price is 50% off through Oct 31. brew install whereisdw/tap/lidnight

Claude Code now resumes after a usage limit — unless your Mac fell asleep

Dawon Lee — Wed, 14 Oct 2026 09:14:49 +0000

If you're on a Claude subscription, recent versions of Claude Code (v2.1.234+) do something quietly great: when a usage limit stops Claude mid-task, the session waits and continues the task on its own after the limit resets.

Usage limit reached · limit resets 3:45pm
Continuing automatically at 3:45pm · esc to cancel

That's exactly what you want for a long refactor you start before bed. There's one catch, straight from the docs:

If it slept for more than about 30 minutes and the limit reset while it slept, the first line reads Your usage limit has reset and the second reads Press enter to continue.

So if your MacBook goes to sleep during the wait — lid closed, or just idle sleep — you wake up to a prompt asking you to press Enter, and the work hasn't moved. The 5-hour window means the wait can easily be a few hours.

(One more catch, pointed out by John Reed in the comments: the wait is interactive-only. Background sessions and claude -p runs don't get it — a rate-limit stop there is just a stop.)

Keeping the Mac awake through the wait

The wait itself uses almost no CPU, which is the problem: from the outside, a session waiting for a reset looks idle.

DIY: if you're at a desk on power, caffeinate -i in another terminal (or caffeinate -w <pid> for the Claude process) blocks idle sleep for as long as Claude runs. Closing the lid on battery is different — macOS sleeps on lid close unless you're in clamshell mode with an external display, and the only switch for that is sudo pmset -a disablesleep 1 (remember to set it back to 0).

Know when the wait starts and ends. Claude Code's hooks tell you exactly:

StopFailure with "error": "rate_limit" fires when a turn ends because of a rate limit.
Notification with notification_type:
- quota_auto_resume_fired — Claude continued after the reset
- quota_auto_resume_stale — the reset happened while the computer slept for 30+ minutes; it's waiting for Enter
- quota_auto_resume_disabled — the wait ended without continuing

A minimal logger to see it happen:

{
  "hooks": {
    "StopFailure": [{ "matcher": "rate_limit", "hooks": [{ "type": "command",
      "command": "echo \"$(date) limit hit\" >> ~/claude-limit.log" }] }],
    "Notification": [{ "matcher": "quota_auto_resume_fired|quota_auto_resume_stale|quota_auto_resume_disabled",
      "hooks": [{ "type": "command", "command": "cat >> ~/claude-limit.log" }] }]
  }
}

With those two signals you can keep the Mac awake from the rate_limit stop until quota_auto_resume_fired (or a few minutes past the 5-hour window), and let it sleep otherwise.

What I did in Lidnight

I build Lidnight, a menu bar app that keeps a MacBook awake with the lid closed while AI agents work and lets it sleep when they're done. It installs the StopFailure hook too: when Claude Code stops on a rate limit, the session shows "limit · resumes in 2h 14m" and the Mac stays awake through a 5-hour wait, so the automatic continue actually happens. quota_auto_resume_fired puts it back to "working".

Update (Oct 17): for the cases Claude Code won't continue on its own — a weekly limit, a stale/disabled wait, or Codex — Lidnight now sends a one-line "please continue" after the reset through official features (Claude Code's cross-session messaging, codex queue). You choose per AI whether that should happen; set it to "paused" and the session stays stopped.

The same docs pass also turned up two notification types I now count as "waiting for you": elicitation_url_dialog (an MCP server asks you to open a URL) and agent_needs_input (a background session needs input). And a reader on Qiita pointed out a subtle one: a sandboxed command's network-access prompt doesn't run PermissionRequest hooks — only the permission_prompt notification catches it (after about six seconds). If you approve prompts from a hook, keep a Notification hook around too.

Lidnight is free with the lid open (AI Auto mode, you turn it on); Pro keeps going with the lid closed, even on battery, and adds auto-start, phone approvals and more — a one-time $9.99 (50% off through Oct 31) with a 7-day trial. brew install whereisdw/tap/lidnight

Sources: Claude Code hooks reference · Wait for a usage limit to reset

How I keep long Claude Code runs alive with my MacBook lid closed

Dawon Lee — Tue, 13 Oct 2026 23:54:59 +0000

I hand Claude Code a lot of long tasks: a refactor across a package, a test suite to fix, a migration that takes a while. The point is to walk away while it works. So I'd start the run, close my MacBook, and leave.

Then I'd come back to a session that had stalled a few minutes in.

This post covers why that happens, what you can do about it with built-in macOS commands, where those commands fall short, and the small menu bar app I ended up building. If you only want the commands, the first half is for you. You don't need the app.

Why closing the lid kills the run

When a Mac sleeps, Claude Code in your terminal stops too. The network drops, API requests fail, and the agent sits there until you wake the machine. Two things cause it: idle sleep (you step away long enough), and lid-close sleep (you shut the laptop).

macOS sleeps the Mac when you close the lid. The one built-in exception is clamshell mode, and that needs a power adapter, an external display, and an external keyboard or mouse all connected. Fine at a desk. Useless in a café, on a train, or when you just want to carry the laptop to another room.

Why `caffeinate` isn't enough

The first thing most of us try is caffeinate:

# keep the Mac awake while one command runs
caffeinate -i your-command

That's a good tool and I still use it for short jobs. But caffeinate, keep-awake apps, and the "Prevent automatic sleeping when the display is off" setting all target idle sleep. Lid-close sleep works separately, so in most setups the Mac still sleeps when you close it, and on battery with no external display it definitely does.

There's also a workflow problem. You have to remember to wrap every run, and an interactive Claude Code session isn't really "one command that exits."

The command that actually works: `pmset disablesleep`

The setting that also disables lid-close sleep is:

# disable sleep entirely, including when the lid closes
sudo pmset -a disablesleep 1

# turn sleep back on
sudo pmset -a disablesleep 0

This works. With it set, you can close the lid on battery and the Mac keeps running.

It also has real risks, and they're why I didn't want to just leave it on:

It's easy to forget to undo. The agent finishes at 2 AM and your Mac keeps running. On battery, that means it drains.
The setting even survives a restart. It's not tied to a session or a process. Whatever state you left it in stays until you change it.
Heat. A MacBook that's awake and closed still makes heat. On a hard surface it vents from the bottom and back, which is fine. In a bag or under a blanket, it can't. A Mac you think is asleep in your backpack is the worst case.

If you go the DIY route, at least tie it to the job so it can't outlive it. A small wrapper with a trap turns sleep back on even if you Ctrl-C:

#!/bin/zsh
# awake-run: keep the Mac awake (lid closed too) only while a command runs
sudo pmset -a disablesleep 1
trap 'sudo pmset -a disablesleep 0' EXIT INT TERM
"$@"

awake-run claude

This still won't protect you from heat, a dying battery, or a crash that skips the trap, and you'll want to check the current state now and then:

pmset -g | grep -i sleep

But it's much better than leaving disablesleep 1 on and hoping you remember.

Knowing when the agent is actually done

The wrapper keeps the Mac awake for as long as the process lives. That's not the same as "while Claude is working." An interactive session can sit idle for hours after the task ends, and keeping the Mac awake all that time is just the "forgot to undo it" problem in another form.

Claude Code has hooks that fire on real events. A Stop hook runs when a task ends, and a Notification hook runs when Claude is waiting for your input or permission. Even without any app, you can get a macOS notification for both by putting this in ~/.claude/settings.json:

{
  "hooks": {
    "Stop": [{ "hooks": [{ "type": "command",
      "command": "osascript -e 'display notification \"Claude Code finished\" with title \"Claude Code\"'" }] }],
    "Notification": [{ "hooks": [{ "type": "command",
      "command": "osascript -e 'display notification \"Claude Code needs you\" with title \"Claude Code\"'" }] }]
  }
}

If you already have a settings file, merge in just the hooks key. It applies to sessions started afterwards.

The limits: you only see those notifications at your Mac, you still have to go back to the terminal to see what needs approval, and if the Mac has gone to sleep, the work has stopped anyway.

Hooks are the right signal, though. They tell you exactly when work starts and ends instead of guessing. That's what I built on.

What I built: Lidnight

Lidnight is a macOS menu bar app that puts those pieces together. It uses the same disablesleep mechanism, but it turns it on and off for you based on whether AI work is actually running.

Detection. When you turn on Claude Code in Settings › Agents, Lidnight adds Claude Code hooks for task start and end, so it knows exactly when Claude is working. Your settings file is backed up first, and turning it off removes only Lidnight's entries. Codex is integrated the same way. Other tools (Gemini CLI, Kiro CLI, Aider, Ollama, LM Studio, and others, 44 in total) are estimated from process activity, plus GPU use for local models. Multiple sessions are tracked separately, and the Mac sleeps only after the last one finishes.

Going back to sleep. In AI Auto mode, once everything has been quiet for 10 minutes, the Mac goes back to sleep normally. When it's unclear whether work is still going, it stays awake. I chose not cutting a run short over saving a few minutes of battery. There's also a Timer mode and an Until mode for tools it can't detect.

The risks from above. These are what I most wanted handled:

If the battery stays above 42°C for over a minute, you get an alert. At 45°C, the Mac goes to sleep. It also sleeps when the battery hits a floor you set.
If the app is force-quit, a watchdog process restores sleep settings. After a sudden power loss, they're restored at the next boot.
It only undoes what it changed: sleep prevention, Low Power and performance modes, fan control, and brightness all go back to their previous values.
Changing the setting needs admin rights, so it installs a small helper that only runs a fixed list of sleep, battery power mode, and fan commands. You can remove it in Settings.

To be clear about heat: the temperature cutoff is a safety net, not permission to put a running Mac in a bag. Keep it on a hard, ventilated surface.

Lid behavior. The default, "Agents use screen," keeps the display on at zero brightness without locking, so agents that control the screen keep working. That also means the session is unlocked while the lid is closed. If you don't want that, pick "Screen off," which turns the display off and locks.

Approving permission prompts without going back to the terminal

The other way a long run stalls is Claude stopping to ask "Can I run this?" while you're away.

Lidnight's hook shows what Claude wants to do (the command, the file it will edit, or the URL) and lets you allow or deny it from:

a card in the menu bar window, buttons on the macOS notification, or a small bunny that shows up just left of the notch only while an agent is waiting (free)
your phone, through the free ntfy app, after linking once with a QR code and no account (Pro)

The normal terminal prompt still appears, and whichever answers first wins.

Approving from a phone is the part I was most careful with:

Push notifications never include the command.
The status page is encrypted end to end on the Mac (AES-GCM), and the key reaches your phone only through the QR code, so the relay server can't read it.
Allow and deny are one-time HMAC signatures. They expire and only work for that one request, so a copied one can't be replayed.
Hard-to-undo commands like rm -rf, git push, or sudo can't be allowed from the phone at all. Those stay Mac-only.
Phone commands only reach a Mac that's awake, and anything more than 10 minutes late is ignored.

Setup: turn on Claude Code in Settings › Agents, make sure "Approve from anywhere" is on (it's the default), and for your phone, turn on phone alerts in Settings › Alerts and scan the QR code. Claude sessions that were already open need one restart to pick it up.

Smaller things that came along

A bunny per agent in the menu bar that runs faster as tokens flow, and gets an amber dot when an agent is waiting for approval.
Claude and Codex 5-hour and weekly limits with reset times, plus token counts and estimated API-price cost by model and project, all read from local logs. These are estimates, not your actual bill.
A CLI (lidnight start, stop, status, doctor) so an agent can switch it on itself before a long job. lidnight doctor checks the helper, sleep prevention, hooks, approvals, and phone link, one line each.

There's no account, and your code and conversations never leave the Mac. The app sends only five anonymous daily counts (no device or ID), and you can turn that off in Settings.

Try it, or just use the commands

If caffeinate -i for short jobs and the pmset wrapper for long ones cover what you need, use those. They're free and they work.

If you'd rather not think about it, Lidnight is at https://lidnight.app/en/, or:

brew install whereisdw/tap/lidnight

It needs an Apple Silicon MacBook on macOS 13 or later. The free tier includes AI Auto mode with the lid open, battery and heat protection, and approvals on the Mac. Pro is a one-time $9.99 for one Mac ($14.99 for three; 50% off through Oct 31), no subscription, and adds keeping going with the lid closed (even on battery), phone alerts and approvals, auto-start when AI work begins, fan boost, and longer stats. Every download includes a 7-day Pro trial with no payment details needed, and there's a 14-day refund.

Getting lid-closed sleep right was more subtle than I expected. If you've hit edge cases with pmset, clamshell mode, or hooks, I'd like to hear about them in the comments.

DEV Community: Dawon Lee

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

A sleeping Mac isn't asleep

What that costs

Fixing it yourself

Doing it only while work runs

Claude Code Remote Control stops when you close the lid. Here's why, and the fix

Why

Fixing it yourself

Doing it only while work runs

You can answer Claude Code's AskUserQuestion from a hook (and from your phone)

What the hook receives

What the hook returns

A minimal test hook

Two things to watch

Using it from a phone

Codex will answer its own question if you're not looking. Here's how to catch it

There's no hook for it

But the session log has it

A small watcher

What I did in Lidnight

Claude Code now resumes after a usage limit — unless your Mac fell asleep

Keeping the Mac awake through the wait

What I did in Lidnight

How I keep long Claude Code runs alive with my MacBook lid closed

Why closing the lid kills the run

Why caffeinate isn't enough

The command that actually works: pmset disablesleep

Knowing when the agent is actually done

What I built: Lidnight

Approving permission prompts without going back to the terminal

Smaller things that came along

Try it, or just use the commands

Why `caffeinate` isn't enough

The command that actually works: `pmset disablesleep`