claude-code - 💡(How to fix) Fix [BUG] Desktop app (Claude for Mac): Quick Entry holds display awake; toggle ignored until restart [1 participants]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

Summary

Claude Desktop on macOS holds a NoDisplaySleepAssertion "Capturing" continuously while Quick Entry is enabled, preventing the display from ever entering idle-sleep. Two related issues:

1. Excessive assertion duration: the assertion is held the entire time Claude.app is running, not just while Quick Entry is being invoked. Even an idle Claude.app with no user interaction blocks the OS-level display-sleep timer.
2. Toggle requires app restart: disabling "Quick access shortcut" in Settings → General → Desktop App does not take effect on the running instance. New Quick Entry assertions continue to fire at the same cadence (once per second in some states) until Claude.app is fully quit and relaunched.

Affected

• Claude Desktop for macOS (current public release as of 2026-05-04)
• macOS Tahoe 26.4.1 (Build 25E253) on Apple Silicon
• Bundle: /Applications/Claude.app/Contents/MacOS/Claude

Steps to reproduce

1. On macOS, install and launch Claude Desktop.
2. Ensure Settings → General → Desktop App → "Quick access shortcut" is on.
3. Verify display-sleep behaviour:

   pmset -g log | grep "PID [0-9]*(Claude).*Capturing" | tail -5

   Expected entries every minute (or more frequently when window is focused), each as paired Created/Released NoDisplaySleepAssertion "Capturing".
4. Walk away from the machine for longer than the configured displaysleep minutes (default 10).
5. Observe: display does not turn off.
6. Then test the toggle: Settings → General → Desktop App → turn "Quick access shortcut" off. Do NOT restart Claude.app.
7. Re-run the same pmset query 30 seconds later. New "Capturing" entries continue to appear with the same frequency.
8. Quit Claude.app completely (Cmd+Q or right-click dock → Quit), then relaunch.
9. Re-run the pmset query. New "Capturing" entries no longer appear. Display now sleeps normally.

Expected behaviour

• Either: Quick Entry should not hold a NoDisplaySleepAssertion while idle. The assertion should be acquired only during actual screenshot/region-selection invocation, not continuously.
• And: the Settings toggle should take effect on the running instance immediately, releasing any held assertions.

Actual behaviour

• Assertion is held continuously on a sub-second / per-second cycle while Quick Entry is enabled.
• Toggling "Quick access shortcut" off has no observable effect until Claude.app is restarted.
• Display can never enter idle sleep while Claude.app is running with the default settings.

Empirical evidence

Captured from pmset -g log on 2026-05-04. Identical pattern observed across a six-hour evening session on 2026-05-03, where assertions fired every minute on the dot for hours:

2026-05-03 18:00:33  PID 970(Claude) Released NoDisplaySleepAssertion "Capturing" ...
2026-05-03 18:01:33  PID 970(Claude) Released NoDisplaySleepAssertion "Capturing" ...
2026-05-03 18:02:33  PID 970(Claude) Released NoDisplaySleepAssertion "Capturing" ...
... (continuing every 60s for hours; system flags throughout: PrevIdle IntPrevDisp kDisp)

Within Claude.app focus state today, the cycle accelerated to every second:

2026-05-04 12:16:45  PID 970(Claude) Created  NoDisplaySleepAssertion "Capturing"
2026-05-04 12:16:45  PID 970(Claude) Released NoDisplaySleepAssertion "Capturing"
2026-05-04 12:16:46  PID 970(Claude) Created  NoDisplaySleepAssertion "Capturing"
2026-05-04 12:16:46  PID 970(Claude) Released NoDisplaySleepAssertion "Capturing"
... (per-second create/release with PrevDisp DeclUser IntPrevDisp flags)

After quitting Claude.app at ~12:17, no new "Capturing" entries appeared. After relaunching with the toggle now off, no new entries appeared. Confirmed via:

pmset -g assertions | grep -i claude   # returns empty

Impact

• macOS users who keep Claude Desktop running cannot rely on the OS-level displaysleep setting.
• Affected behaviours: screen burn-in risk on OLED external displays, increased ambient power draw at home/office, faster battery drain on laptop battery, defeats sleep schedules on shared/managed machines.
• Particularly impactful for users like me who keep Claude open all day: my display did not sleep last night between 18:00 and ~22:25 despite multiple multi-tens-of-minutes idle periods. The display only slept once Claude.app entered some other state at 22:26.

Workaround currently in use

Disable the Quick Entry shortcut, then quit and relaunch Claude.app. Voice shortcut may need the same treatment (untested in this report).

Suggested fix direction

1. Acquire the screen-capture session lazily on first Quick Entry invocation rather than at app launch. Release after a short cooldown of inactivity.
2. Tie the assertion lifecycle to the actual capture operation rather than to the feature being enabled.
3. Honour the Settings toggle on the running instance — releasing any held capture session and assertion when the toggle flips off.
4. If a continuous capture session is genuinely required by macOS for permission warm-up, consider using kIOPMAssertionTypePreventUserIdleDisplaySleep only during the brief interval from shortcut press to capture completion, rather than holding it continuously.

How I'd verify a fix

Once a fix ships, the diagnostic remains:

pmset -g log | grep "PID [0-9]*(Claude).*Capturing" | tail -20

Expected: no entries during normal idle use. Entries should appear only in the seconds surrounding actual Quick Entry invocations.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

Claude 1.5354.0 (9a9e3d)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

No response