Don't use
OpenClaw.
Use cron and Claude CLI instead.

I tried OpenClaw for a week and decided the security tradeoff wasn't worth it. Here's what I run instead: Claude CLI in non-interactive mode, scheduled by cron.

For about a week I ran OpenClaw, an AI gateway that lets you run Claude on a schedule with a UI on top. It's slick. I wanted to like it. After enough testing I decided the security tradeoff wasn't worth what I was getting back, and I tore it out. Here's why, and what I switched to.

The Risk vs. Reward Didn't Pencil

I wrote about risk vs. reward in AI-assisted work elsewhere on this blog and the same lens applies here. A gateway service has to hold real credentials and run on your behalf. That's a lot of trust to extend to a third party for the convenience of a UI on top of cron. For my use cases, none of which are urgent or interactive, that convenience didn't justify expanding the attack surface.

What I Run Instead

A handful of cron jobs that invoke claude in non-interactive mode. That's it. Each job has its own scope, its own MCP config, and its own keys. If one job breaks, it doesn't take the others with it. If I need to know what a job did, I read its log file.

At a high level, the setup looks like this:

Cron schedules a small shell script.
The script runs Claude CLI in non-interactive mode with a focused prompt and the MCP config scoped to that job.
Output goes to a log file. Anything that needs human attention gets posted to a Slack channel via a logging MCP.
That's the whole rig.

Tips If You're Going to Run Claude on a Schedule

Use non-interactive mode. One shot, exits cleanly. No interactive prompts to be auto-confirmed in ways you didn't expect.
Read-only API access by default. Same rule as the main article on responsible AI use. Most automations don't need write access. The ones that do should be locked down per job.
Production data is a separate category. I never point a scheduled job at prod for "diagnostic" runs. The blast radius if Claude misinterprets the prompt is too high. There are documented stories of AI assistants accidentally wiping a production database during what was supposed to be local debugging. Don't be that story.
Manual confirmation gates for destructive actions. Anything that mutates state, opens a PR, sends an email, posts to a channel, gets a manual gate of some kind. A Slack confirmation, a draft state, a separate human-approval step. The cron job opens the door; a human steps through it.
One job, one scope. Don't share a config across automations. If the GitHub job and the SEO job each need their own narrow keys, give them their own narrow keys.

Why This Beats a Gateway, For Me

I can audit it. The cron entries, the shell scripts, the MCP configs, they're all in version control or on the server, and they're all simple enough to read in a sitting.
The blast radius is bounded. OS-level permissions I've already spent years configuring do most of the work. A gateway adds a new permission system on top of that, and now I have to trust two systems instead of one.
No third party between me and the model. Fewer vendors in the loop, fewer breach surfaces, fewer terms of service to re-read.

A managed gateway might be the right call for a team that wants a UI and a built-in audit trail without building one. For a one-person shop, it's almost always more friction than it's worth.

TL;DR