Headless Mac Mini as an AI Server: Power Tips for Running OpenClaw 24/7

Running a locally-hosted AI agent platform sounds great on paper. No cloud costs, no latency surprises, full control over your models. Plug in a Mac Mini, run openclaw gateway start, and your agents are live on Telegram 24/7.

Then you wake up the next morning and your bots haven't replied to anything since midnight.

This is the story of what went wrong and the three fixes that made it stop.

The Setup#

I'm running OpenClaw on an M4 Mac Mini. The machine has no monitor, keyboard, or mouse attached (headless mode). It sits in a corner and is supposed to just work. The agents use a mix of local Ollama models and OpenAI API calls, and they communicate with users via Telegram.

The problems I hit:

1. The Mac would go to sleep, silencing every agent until I SSH in and wake it up
2. The Telegram gateway would silently stall after about 8 minutes, looking alive but not polling
3. Agent memory reads would crash overnight because daily log files didn't exist yet

Three problems, three fixes. Let's go.

Fix 1: Power Management#

A Mac Mini in headless mode is just a computer waiting for an excuse to sleep. Without a monitor attached, macOS doesn't always register it as an "active display" device, and the default power settings are tuned for a desktop someone is actually sitting in front of.

Run this once and you're done:

sudo pmset -a sleep 0 disksleep 0 displaysleep 0 ttyskeepawake 0 autorestart 1

Here's what each flag does:

The -a flag applies settings to all power modes (AC, battery, UPS). On a Mac Mini there's only AC, but it's a good habit.

After this change, the Mac stays awake indefinitely. SSH sessions connect instantly. Agents stop going silent overnight. Problem one solved.

Fix 2: The Telegram Polling Bug#

This one is more subtle and more annoying.

OpenClaw uses Telegram's long-polling API to receive messages. The gateway opens a connection to Telegram's servers and waits. When a message arrives, the connection returns it. The gateway processes it and opens another connection.

The problem: Telegram's long-polling connections have a timeout. After roughly 8 minutes of no activity, the connection dies. OpenClaw's gateway doesn't always notice this gracefully. The process keeps running, everything looks fine, but it has silently stopped polling. Your bots are deaf.

The fix is a watchdog cron that checks whether the gateway is still polling and restarts it if it isn't. Here's the script at ~/.openclaw/scripts/gateway-watchdog.sh:

#!/bin/bash
# gateway-watchdog.sh - Restart OpenClaw gateway if Telegram polling has stalled
set -euo pipefail

LOG_FILE="$HOME/.openclaw/logs/watchdog.log"
MAX_SILENT_SECONDS=600  # 10 minutes without Telegram activity = stalled

# Find the active gateway log (date-based filename in temp dir)
TMPDIR_BASE="/var/folders"
TODAY=$(date +%Y-%m-%d)
GATEWAY_LOG=$(find "$TMPDIR_BASE" -path "*/openclaw-*/openclaw-${TODAY}.log" -readable 2>/dev/null | head -1)

# Fallback to static log location
if [ -z "$GATEWAY_LOG" ]; then
    GATEWAY_LOG="$HOME/.openclaw/logs/gateway.log"
fi

log() {
    echo "$(date -u +"%Y-%m-%dT%H:%M:%SZ") $1" >> "$LOG_FILE"
}

# Check if gateway is running
if ! pgrep -f "openclaw.*gateway" > /dev/null 2>&1; then
    log "WARN: Gateway not running. Starting..."
    openclaw gateway install > /dev/null 2>&1
    openclaw gateway start > /dev/null 2>&1
    log "INFO: Gateway started."
    exit 0
fi

# Check last Telegram activity in gateway log
if [ -f "$GATEWAY_LOG" ]; then
    LAST_TELEGRAM=$(grep -E "\[telegram\]" "$GATEWAY_LOG" 2>/dev/null | tail -1 \
        | grep -oE "^[0-9]{4}-[0-9]{2}-[0-9]{2}T[0-9]{2}:[0-9]{2}:[0-9]{2}" || echo "")

    if [ -n "$LAST_TELEGRAM" ]; then
        LAST_EPOCH=$(date -j -f "%Y-%m-%dT%H:%M:%S" "$LAST_TELEGRAM" +%s 2>/dev/null || echo 0)
        NOW_EPOCH=$(date +%s)
        SILENT=$((NOW_EPOCH - LAST_EPOCH))

        if [ "$SILENT" -gt "$MAX_SILENT_SECONDS" ]; then
            log "WARN: Telegram silent for ${SILENT}s. Restarting gateway..."
            openclaw gateway stop > /dev/null 2>&1
            sleep 3
            openclaw gateway install > /dev/null 2>&1
            openclaw gateway start > /dev/null 2>&1
            log "INFO: Gateway restarted after ${SILENT}s silence."
        fi
    fi
fi

# Rotate watchdog log if over 1MB
if [ -f "$LOG_FILE" ]; then
    LOG_SIZE=$(stat -f%z "$LOG_FILE" 2>/dev/null || echo 0)
    if [ "$LOG_SIZE" -gt 1048576 ]; then
        tail -100 "$LOG_FILE" > "$LOG_FILE.tmp"
        mv "$LOG_FILE.tmp" "$LOG_FILE"
        log "INFO: Watchdog log rotated."
    fi
fi

The logic is straightforward: grep the gateway log for the last [telegram] line, parse its timestamp, and if it's more than 600 seconds ago, restart the gateway. It also handles the case where the gateway isn't running at all (which can happen after a power cycle if autorestart didn't catch it).

Make it executable and add it to cron:

chmod +x ~/.openclaw/scripts/gateway-watchdog.sh

# Add to crontab (runs every 5 minutes)
crontab -e

Add this line:

*/5 * * * * /Users/your-username/.openclaw/scripts/gateway-watchdog.sh

With this running, the worst case is a bot that's silent for up to 5 minutes before the watchdog notices and fixes it. In practice, agents are usually back within a minute of the cron firing.

Fix 3: Daily Memory Log Creation#

This one is a smaller gotcha but caused genuine confusion before I tracked it down.

OpenClaw agents write to daily log files for memory and activity tracking. The file path typically includes the current date, something like ~/.openclaw/logs/memory-2026-03-06.log. The agents expect these files to exist before they try to append to them.

When they don't exist (first write of the day), the agent crashes with ENOENT: no such file or directory. The error happens at whatever time the first agent wakes up and tries to write. If that's 3am, you have a quiet night. If an agent is actively talking to someone, it looks like a crash.

The fix is a cron that creates the daily log file at midnight:

# Create daily memory log before agents try to write to it
0 0 * * * touch /Users/your-username/.openclaw/logs/memory-$(date +\%Y-\%m-\%d).log

One note on the date command in cron: the % character has special meaning in crontab and must be escaped as \%. That's why the line uses \%Y-\%m-\%d instead of %Y-%m-%d.

The Combined Crontab#

Here's what the full crontab looks like after all three fixes (the pmset command is a one-time setup, not a cron):

# OpenClaw maintenance jobs
*/5 * * * * /Users/your-username/.openclaw/scripts/gateway-watchdog.sh
0 0 * * * touch /Users/your-username/.openclaw/logs/memory-$(date +\%Y-\%m-\%d).log

Clean. Two jobs. One keeps the gateway alive, one makes sure daily files exist before agents need them.

The Result#

After these three changes, the Mac Mini has been running continuously for several days with zero intervention. The bots respond. The agents write their logs. The watchdog fires occasionally (always successfully), and the power management keeps the whole thing awake and ready.

Lessons Learned#

The whole setup took maybe two hours to get right, including the time spent debugging the polling stall. The Mac Mini has been silent in the corner ever since, doing its job.

That's the goal.

References#

• Headless Mode Infographic: A visual step-by-step guide covering all three fixes in a single overview.
• Building a Hardened AI Server Stack (PDF): A 10-page reference document covering the full engineering approach, including network stall mechanics, the reliability triad, and the "pragmatic over perfect" philosophy.

Written by Chris Johnson and edited by Claude Code (Sonnet 4.6). Part of the Quick Tips series: short, practical posts about things I actually ran into and fixed. The OpenClaw deployment series (parts 1-3) covers the full setup story if you want the longer version.