Open Source Claude Code Schedulers: What's Actually Out There

If you've tried running Claude Code on a schedule and gone looking for tooling, you've probably found a landscape that's fragmentary and evolving fast. There are CLI wrappers, cron scripts, GitHub projects with recent commits, and a few proper applications — and it's not immediately obvious how they differ or which one fits what you're trying to do.

This post is an honest look at the main tools in the space: what they are, what approach they take, and where each one makes sense.

A small caveat up front: this is a young ecosystem and projects change quickly. Check each project's current state before making a decision based on this comparison.

What You're Actually Evaluating

Before getting into specifics, it helps to know what to look for. The core problem — running Claude Code without babysitting it — surfaces a few specific requirements that separate useful tools from barely-working ones:

Silence detection. Claude Code can hang waiting for interactive input in headless mode. A scheduler with no timeout mechanism will sit there all night, spending tokens and doing nothing. This is arguably the most important reliability feature.

Run history. If you can't tell whether last night's job succeeded, you don't have a scheduler — you have a script. Structured logs with timestamps and status are basic hygiene.

Failure handling. What happens when a job fails? Does it stop cleanly? Does it retry? Does it surface diagnostic context? The answer varies significantly across tools.

Ongoing reliability. Does the tool keep running if the machine restarts? If the process crashes? This matters a lot for anything you want to run unattended for weeks at a time.

The Landscape

The tools in this space roughly fall into three categories: CLI-based wrappers and scripts you manage yourself, purpose-built scheduling applications, and project-specific GitHub repos that sit somewhere between the two.

CLI Tools and Scripts

The simplest approach is also the most common starting point: a shell script wrapping claude -p "goal" --project /path and a cron entry. There's no project to install — just bash.

This works for simple cases and many developers start here. The gaps are well-documented elsewhere: no silence detection by default, flat log files, no structured history, and macOS Full Disk Access requirements for cron to reach your development directories. For a single overnight job on a project you check daily, it's fine. For anything more, the edges start to show.

Tools like claudecron build on this basic model with a bit more structure — a CLI interface that makes it easier to define and manage multiple jobs without editing cron directly. If you're comfortable in the terminal and want minimal dependencies, this approach is worth a look. The trade-off is that it's still fundamentally a script runner: the reliability floor is only as high as you make it through manual configuration.

GitHub Projects

claude-code-scheduler is a GitHub project that takes a slightly more structured approach than raw cron — defining jobs in a config file rather than crontab, with some basic logging. It's lightweight and inspectable, which is appealing if you want to know exactly what's running on your machine.

The honest assessment is that most projects in this category are solo or small-team tools built to scratch a personal itch and open-sourced. They're often a good fit for developers who want something simple and don't mind doing a bit of maintenance. They're not a good fit if you need reliable unattended execution over months without touching the configuration.

runCLAUDErun takes a different angle — it's focused on making it easy to run and re-run Claude Code jobs from a simple interface, with more emphasis on the workflow ergonomics than on deep scheduling features. If your use case is more about repeatability and quick re-runs than scheduled overnight automation, it's worth evaluating on those terms.

Desktop Applications

OpenHelm — this is our tool, so take that context as you read — is a macOS desktop app in the menu bar. It's the only product in this space that isn't a CLI tool or GitHub project, and the trade-offs that come with that are real: it requires macOS, it's a download rather than a brew install, and it's fair source (BSL 1.1) rather than MIT or Apache.

What that approach enables is the features that are hard to build well in a script:

Active silence detection. The output stream from every run is monitored in real time. No output for 10 minutes flags the run and stops it — catching the most common and most expensive headless failure mode before it runs up a bill overnight.

Pre-flight checks. Before each run, OpenHelm verifies the project directory exists, the Claude Code binary is accessible, and the job is still valid. If a check fails, the run is immediately marked permanent_failure. Claude Code never launches into a broken environment.

Self-correction loop. Failed runs can automatically queue a corrective retry with the failure output included as context for the next attempt. This works better in practice than it sounds on paper — Claude Code's second pass often succeeds specifically because it's working with information about what went wrong.

Structured run history. Every run produces a timestamped record: status, full output, duration. The question "did last night's job succeed?" takes one click to answer.

Crash recovery. If OpenHelm or the Mac was force-quit mid-run, the next startup detects runs stuck in running state and marks them correctly before the scheduler resumes.

Side-by-Side

Which One Should You Use?

If you're running one or two jobs, you're comfortable with the terminal, and you check the results every morning: a cron script with a hard timeout (timeout 7200 claude -p "goal") covers most of what you need. It's transparent, requires nothing extra, and you know exactly what it's doing.

If you want config-file job management without installing a desktop app: claude-code-scheduler is a reasonable step up. Inspect the source, keep an eye on the commit history, and contribute back if you find issues.

If quick re-runs and workflow ergonomics matter more to you than scheduling: runCLAUDErun is worth a look for its specific strengths.

If you're running multiple jobs across projects, you want reliable unattended execution without babysitting, and silence detection and structured history matter to you: OpenHelm is what those requirements point to.

The ecosystem is still forming. The "right" answer today might not be the right answer in six months. Whatever you choose, the investment in writing well-scoped goals with clear acceptance criteria will pay off regardless of which tool is underneath.