¿Qué mantiene tu Mac despierta? Así lo puedes averiguar

Cómo funcionan las power assertions de macOS

macOS no entra en reposo solo por un temporizador. Antes de atenuar la pantalla o detener el disco, el kernel revisa si algún proceso en ejecución tiene una power assertion activa: una solicitud presentada a través del framework de gestión de energía IOKit que le dice al sistema que necesita seguir despierto. macOS respeta esa solicitud hasta que el proceso la libera o termina.

Dos tipos de assertion explican la mayor parte del comportamiento del reposo. PreventUserIdleSystemSleep bloquea que la Mac entre en reposo por completo: disco, pantalla, todo. PreventUserIdleDisplaySleep solo mantiene la pantalla encendida y deja que el resto del sistema duerma si quiere. Un gestor de descargas, un reproductor de video, caffeinate ejecutado desde Terminal, o una app para mantener la Mac despierta como LidRun pueden sostener cualquiera de los dos tipos, por distintas razones.

Las assertions no son un error: son una función diseñada a propósito, y el mismo mecanismo funciona en ambos sentidos. El bloqueo que mantiene una Mac despierta durante una tarea de IA que corre toda la noche es exactamente el mismo mecanismo que usa una pestaña del navegador olvidada para mantenerla despierta después de que el video terminó. La meta no es desconfiar de cada assertion; es saber cuáles pediste tú y cuáles aparecieron sin invitación.

Usar Monitor de Actividad para encontrar la causa

Abre Monitor de Actividad desde Aplicaciones → Utilidades, o búscalo con Spotlight. Haz clic en la pestaña Energía. La columna Impide reposo muestra Sí o No para cada proceso que el sistema está rastreando; haz clic en el encabezado de la columna para ordenar y que las assertions activas queden arriba.

Las sorpresas más comunes en esa lista: una pestaña del navegador con un video en pausa, un cliente de sincronización en la nube subiendo archivos, una copia de Time Machine que sigue corriendo en segundo plano, una app de podcasts, o una videollamada que quedó abierta después de que saliste de la reunión. Haz clic derecho sobre una entrada sospechosa y elige Inspeccionar proceso para ver su ruta binaria completa y su proceso padre; con eso casi siempre queda resuelto.

Monitor de Actividad es un buen primer paso, pero tiene puntos ciegos. Las herramientas CLI y los daemons en segundo plano —incluido caffeinate lanzado desde Terminal— a veces aparecen bajo un nombre genérico, o directamente no figuran en la lista. Para esos casos, el comando de Terminal de abajo da una imagen más completa.

Leer pmset -g assertions en Terminal

Abre Terminal y ejecuta pmset -g assertions. La salida lista cada power assertion activa en el sistema: el tipo, el nombre legible que le puso la app, y el ID del proceso que la presentó. Un bloque de resumen arriba las separa en Listed (activas en este momento) y Timed Out (el temporizador se cumplió, pero la app nunca llamó a release).

Una assertion con timeout cumplido igual puede bloquear el reposo: el proceso fijó un plazo, el plazo pasó, pero el bloqueo en sí nunca se liberó. Si un PID en la salida no te resulta familiar, cotéjalo con ps aux | grep, seguido de ese PID, para confirmar a qué proceso pertenece. Algunas assertions llevan un timeout explícito; otras son indefinidas: una PreventUserIdleSystemSleep indefinida sostenida por un agente en segundo plano congelado o caído mantiene la Mac despierta sin causa visible, y es lo primero que vale la pena revisar si la máquina lleva encendida mucho más tiempo del esperado.

pmset -g assertions solo muestra lo que está activo en este momento, no tiene memoria. Dos comandos relacionados cubren esos huecos. El pmset -g simple (sin la bandera assertions) incluye una línea SleepDisabled: un ajuste distinto, global, que algunas herramientas —y el propio modo Closed-Lid de LidRun— activan con pmset -a disablesleep en lugar de presentar una assertion normal (más sobre esto en la siguiente sección). Y pmset -g log imprime una línea de tiempo histórica de eventos de reposo, despertar y assertions, útil si quieres saber qué mantuvo la Mac despierta durante la noche en vez de justo ahora.

Para detener una assertion de CLI como caffeinate, busca su PID en la salida de pmset y ejecuta kill seguido de ese PID. Cerrar una app también libera sus assertions de inmediato: las assertions normales están atadas al proceso, así que macOS las borra en el instante en que el proceso termina, sin ningún paso de limpieza aparte. Si una assertion no muestra un dueño claro, o su proceso ya se cayó, un reinicio borra todos los bloqueos pendientes.

Cuando pmset -g assertions no devuelve nada

A veces pmset -g assertions no devuelve absolutamente nada, y aun así la Mac parece no apagarse del todo: el ventilador sube y baja, o la pantalla parpadea encendida sin ninguna app a la vista. Por lo general eso no es una assertion oculta; es un dark wake programado. macOS despierta brevemente y de forma periódica para tareas de red —sincronización de iCloud, Find My, Handoff y Power Nap— incluso sin nada reteniendo un bloqueo, y vuelve a dormirse solo segundos después.

Si quieres descartarlo, ve a Ajustes del Sistema → Batería → Opciones y desactiva Activar para acceso a la red. Esto no detiene una assertion genuina —si algo realmente está presentando PreventUserIdleSystemSleep, ese ajuste no lo toca— pero elimina el ruido de fondo para que una nueva revisión con pmset -g assertions sea más fácil de leer.

Este es también el momento de revisar el pmset -g simple en busca de una línea SleepDisabled: 1, descrita arriba. No aparecerá bajo pmset -g assertions porque no es una assertion: es un ajuste de sistema permanente, casi siempre dejado activo por pmset -a disablesleep desde un script, una herramienta de terceros, o una app (incluido el modo Closed-Lid de LidRun) que se cayó antes de poder desactivarlo por sí misma.

Assertions intencionales vs. no deseadas

No todas las assertions hay que eliminarlas. Si tienes una sesión larga de Claude Code corriendo, una tarea de modelo local, o un agente de Cursor trabajando toda la noche, algo debería estar reteniendo esa assertion; matarla mataría también tu trabajo. La pregunta real no es solo '¿por qué mi Mac está despierta?' sino '¿yo pedí esto?'

Un gestor de descargas que retiene la prevención de reposo hasta que termina una transferencia está haciendo su trabajo. Un reproductor de video que la retiene después de que cerraste la ventana, no. Una herramienta que configuraste a propósito —LidRun, caffeinate -i ejecutado a mano— es intencional. Una pestaña del navegador con un video en pausa que olvidaste, no lo es. La diferencia está en el consentimiento, no en el mecanismo.

Si tu respuesta es 'sí, esto lo quiero', ya tienes opciones nativas y gratis. caffeinate -i, ejecutado desde Terminal, presenta la misma assertion PreventUserIdleSystemSleep descrita antes durante todo el tiempo que el comando siga corriendo; agrega -t 3600 para un límite de una hora. Está atado al proceso, así que terminar el comando o cerrar la ventana de Terminal la libera automáticamente. Eso sí, caffeinate no sirve con la tapa cerrada: una assertion de idle-sleep no alcanza al clamshell sleep. La única palanca gratuita ahí es sudo pmset -a disablesleep 1, y se comporta distinto a propósito: es un ajuste global y permanente, no atado a un proceso, así que sobrevive incluso si la app que lo activó se cae, y queda activo hasta que algo ejecute explícitamente pmset -a disablesleep 0 o la Mac se reinicie. Apps de la barra de menú como Amphetamine, KeepingYouAwake, Lungo y Caffeine envuelven el mismo mecanismo de fondo en un interruptor de un clic, que es una opción perfectamente válida si lo único que necesitas es un switch manual. De cualquier forma, sigue siendo la misma assertion o la misma bandera disablesleep por debajo, que es justo por lo que vale la pena conocer pmset -g assertions sin importar qué herramienta presentó el bloqueo. La comparación LidRun vs caffeinate recorre el desglose completo de costo y funciones.

Para un bloqueo que quieres mantener pero de forma segura, lo que importa son las salvaguardas: un corte automático antes de que la batería baje a un nivel peligroso, conciencia del estado térmico para que una Mac caliente no se mantenga despierta indefinidamente, y limitar la assertion a una sola tarea para que se libere en el momento en que esa tarea termina en vez de depender de que alguien se acuerde. El Auto Mode de LidRun se encarga de ese alcance: le indicas el nombre de un proceso —una sesión de Claude Code, un build, un trabajo de render— y sostiene la assertion solo mientras ese proceso está corriendo, y la libera en el instante en que el proceso termina. Agente corriendo, se mantiene despierta; agente terminado, se libera: ese es todo el diseño, no un bloqueo ciego que queda encendido hasta que alguien se acuerda de apagarlo. La guía mantener la Mac despierta solo mientras trabaja explica ese patrón en detalle. Con batería, LidRun también se detiene por debajo de un umbral —20% por defecto, ajustable entre 15% y 50%— sin importar qué siga corriendo, y sale del modo Closed-Lid en cuanto el sistema reporta presión térmica crítica (con una advertencia en la etapa seria previa a eso), porque una tapa cerrada bloquea la vía principal de enfriamiento de la Mac y ninguna automatización debería mantenerla cerrada mientras se está sobrecalentando.

Cuando el culpable no es deseado, cerrar la app lo soluciona de inmediato. Si el mismo proceso sigue reapareciendo después de reiniciar, revisa Ajustes del Sistema → General → Elementos de inicio y en segundo plano en busca de agentes configurados para lanzarse automáticamente. Quitar o desactivar el elemento de inicio corta el ciclo desde la raíz.