Claude Code Cron Jobs: Desktop App vs CLI — Which to Use?

There are two ways to set up Claude Code cron jobs on macOS. The first is the traditional route: a shell script wrapping the claude CLI, a crontab -e entry, and a log file. The second is a desktop app like OpenHelm, which handles the scheduling, logging, and failure management through a GUI.

Both work. The question is which one works better for your situation — and the answer depends less on technical skill than on what you actually need.

The CLI Approach

The basic shell + cron pattern looks like this:

#!/bin/bash
# ~/scripts/nightly-claude.sh
LOG="$HOME/claude-logs/nightly-$(date +%Y%m%d).log"
mkdir -p "$(dirname "$LOG")"

claude -p "Run the test suite and fix any failing tests. If you can't fix a failure in 3 attempts, document it in FAILURES.md and stop." \
  --project /Users/you/myproject \
  >> "$LOG" 2>&1

Then in cron:

0 2 * * * /Users/you/scripts/nightly-claude.sh

That's it. It runs at 2am every night, writes output to a log file, and you check it in the morning.

Where this works well: Single project, single job, developer who's comfortable in the terminal and will actively check log files each morning. If that's you, this is enough. The overhead of any additional tooling isn't worth it for a setup this simple.

Where it starts to crack: Multiple projects. Silence detection. Run history you can actually query. Failure handling that doesn't require writing custom shell logic.

The Desktop App Approach

A macOS desktop app like OpenHelm provides the same scheduling functionality through a GUI, with features built around the specific failure modes of headless AI agent execution:

Silence detection. The most expensive gap in the cron approach. Claude Code can hang in headless mode — waiting for an interactive prompt, caught in a loop, blocked on a stalled process — and a cron script has no way to detect it. The job keeps running, consuming tokens, until you notice. OpenHelm monitors the output stream and stops runs after 10 minutes of no output.

Structured run history. Log files are flat text sorted by date. Checking "did the job succeed last night?" means cat-ing a file or grepping for keywords. In OpenHelm, it's a status label on a dashboard entry — succeeded, failed, permanent_failure.

Self-correction. When a job fails, OpenHelm can queue a corrective retry with the failure output passed back to Claude Code. The second attempt often succeeds because it has context about what went wrong. Cron just runs the same command again from scratch.

Schedule types. Cron has one model: "fire at this time on this pattern." OpenHelm has five: calendar, interval (from completion), cron, once, and manual. The interval type is specifically designed for variable-duration AI jobs — it fires N hours after the previous run *completed*, not after it *started*. This prevents job pile-up when a session runs long.

Trade-offs That Actually Matter

The setup time comparison is the key one. The cron approach is faster for one job. Once you have three projects and five jobs, you're managing five cron entries, five shell scripts, and custom logging for each — while a desktop app is managing all of them through the same interface.

macOS Permissions and Cron

One practical point about cron on modern macOS that's worth knowing: cron requires Full Disk Access to reach your development directories. You need to grant this in System Settings → Privacy & Security → Full Disk Access, adding /usr/sbin/cron.

Without this, your cron jobs will fail silently when trying to access code in your home directory — which is a confusing failure mode if you haven't encountered it before.

OpenHelm handles its own permissions as a macOS application and doesn't require this manual step.

When to Use Each

Use cron + CLI if:

• You have one or two jobs and check them actively each morning
• You're comfortable with shell scripting and prefer full transparency into what's running
• You're on Linux (OpenHelm doesn't run there)
• You're experimenting and don't want to commit to any particular tool yet

Use a desktop app if:

• You're running three or more recurring jobs across multiple projects
• You need silence detection (overnight automation where cost matters)
• You want structured run history without building it yourself
• You prefer a GUI for monitoring job status

A common pattern is to start with cron, learn how Claude Code behaves headlessly on a few test jobs, and then switch to a desktop app once the value of structured logging and silence detection becomes apparent from experience. That's a reasonable progression — the cron approach teaches you what the gaps are before you reach for something that fills them.

Practical Tips for Cron-Based Claude Code Jobs

If you're going the cron route, a few things that make it meaningfully more reliable:

Add a hard timeout. The timeout command kills a process after N seconds regardless. timeout 7200 claude -p "..." prevents an 8-hour silence scenario at the cost of killing legitimate long runs. Choose the value based on what's acceptable for your job.

Log both stdout and stderr. >> "$LOG" 2>&1 captures both streams. Without 2>&1, error messages go nowhere and you'll spend time wondering why the job "ran" without producing output.

Test the script manually first. Before adding a cron entry, run the script directly from a terminal as the same user cron will use. Permission issues and path problems surface immediately this way.

Check the log the next morning. This sounds obvious, but building the habit is what makes overnight automation actually reliable. If you're not reviewing what ran, you're not automating — you're just hoping.

For more on building that review habit and writing goals that work reliably without supervision, the overnight automation guide covers both in more detail.