Immediate sleep after waking

[nihaals]

Sometimes after waking up my M1 MacBook Pro with a monitor always connected, my laptop goes back to sleep a couple seconds after waking and unlocking. I then have to unlock again.

I added some logs and it seems to be hitting

noclamshell/noclamshell

Line 18 in c0985c3

pmset sleepnow

during this. I have mine running every 10 seconds and it took a few times to intentionally reproduce so the cause might be the script running during wake when the other monitor is still turning on/connecting.

Maybe there's a way to track time since last wake and if it's less than ~10 seconds then ignore it? I can also try logging more values to help find a way to differentiate/find the root cause if there's any more useful context I can gather.

One idea of a cause is that ioreg -r -k AppleClamshellState | grep AppleClamshellState | grep Yes takes ~25ms and all the pmset commands take ~750ms, so if the script runs during sleep, sees the lid is closed and then during the 750ms of pmset -g powerstate | grep AppleDisplay | grep USEABLE (or maybe even the following commands, I'm not sure what DCPDPDeviceProxy and DCPDPServiceProxy represent) running the lid is opened and the system wakes up, it looks like the lid is closed and the system is awake, so we go to sleep.

[nihaals]

Currently trying swapping the checks to see if that works:

NUM_DEVICE_PROXY=$(pmset -g powerstate | grep -c DCPDPDeviceProxy)
NUM_SERVICE_PROXY=$(pmset -g powerstate | grep -c DCPDPServiceProxy)
ARM_AWAKE=$(( 0 < NUM_DEVICE_PROXY && NUM_DEVICE_PROXY < 4 ||
      0 < NUM_SERVICE_PROXY && NUM_SERVICE_PROXY < 4 ))
if [ "$ARM_AWAKE" ]; then
  LID_CLOSED=$(ioreg -r -k AppleClamshellState | grep AppleClamshellState | grep Yes)
  if [ "$LID_CLOSED" ]; then
    pmset sleepnow
  fi
fi

[FernandoMiguel]

oh i get this all the time, but never bother to think it was noclamshell

[pirj]

Analyzed the script with Claude. I didn't try to reproduce in practice. Can you try?

---

Looking at this script, I can identify the root cause of the issue. Let me analyze it step by step.

The Bug

There's a critical logic error on line 17:

ARM_AWAKE=$(( 0 < NUM_DEVICE_PROXY && NUM_DEVICE_PROXY < 4 ||
0 < NUM_SERVICE_PROXY && NUM_SERVICE_PROXY < 4 ))
if [ "$ARM_AWAKE" ]; then

The problem: $(( ... )) returns a number (0 or 1), not a boolean. When you test [ "$ARM_AWAKE" ], bash checks if the string is non-empty. Both "0" and "1" are non-empty
strings, so this condition is always true.

This means on ARM Macs, whenever the lid is detected as closed, the script unconditionally runs pmset sleepnow.

The Race Condition

When a user opens the lid:

1. User opens lid → macOS begins wake/unlock sequence
2. Script runs during the 5-second interval
3. AppleClamshellState may still report "Yes" (closed) for a brief moment during the transition
4. Due to the bug above, pmset sleepnow fires immediately
5. User's Mac goes back to sleep mid-unlock

The Fix

Change line 17 from:
if [ "$ARM_AWAKE" ]; then

To either:
if [ "$ARM_AWAKE" -eq 1 ]; then

Or use arithmetic evaluation (more idiomatic):
if (( ARM_AWAKE )); then

The second form is preferred because (( 0 )) is false and (( 1 )) is true in bash arithmetic context.

---

[nihaals]

It's true:

ARM_AWAKE=$(( 0 < 1 ))
if [ "$ARM_AWAKE" ]; then
  echo true
else
  echo false
fi

ARM_AWAKE=$(( 0 > 1 ))
if [ "$ARM_AWAKE" ]; then
  echo true
else
  echo false
fi

ARM_AWAKE=$(( 0 < 1 ))
if (( ARM_AWAKE )); then
  echo true
else
  echo false
fi

ARM_AWAKE=$(( 0 > 1 ))
if (( ARM_AWAKE )); then
  echo true
else
  echo false
fi

true
true
true
false

I'm testing this now to see if ioreg can stay before pmset.